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rogram.  The  JSDD  should  be  Integrated  Into  a comprehensive  analysis  and 
ocuaantatlon  system  In  order  for  It  to  realise  Its  full  potential.  The  JSDD  Is 
mplemanted  la  JOVIAL  J3  as  a three  program  system  designed  to  run  on  a Honeywell 
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* JOVIAL  Structured  Design  Diagrammer  (JSDD) 

Report  Summary 

This  document  is  a summary  of  the  contents  of 
the  JSDD  Final  Report. 

* JOVIAL  Structured  Design  Diagrammer  (JSDD) 

Final  Report 

This  volume  presents  .the  design  techniques 
for  implementing  the  JSDD  and  describes  the 
use  of  Structured  Design  Diagrams. 

* JOVIAL  Structured  Design  Diagrammer  (JSDD) 

Program  Description 

This  volume  presents  a detailed  description 
of  the  program  implementation  for  purposes  of 
maintaining  and/or  modifying  the  JSDD. 


* JOVIAL  Structured  Design  Diagrammer  (JSDD) 
User^s  Manual 

This  volume  presents  the  user*'s  view  of  the 
JSDD  along  with  user  options  and  other 
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t 1.  Introduction 

[ In  recent  years,  the  digital  computer  software  Industry  has 

[ directed  considerable  effort  toward  the  development  of 

- design  and  implementation  methodologies  to  ensure  the 

E sufficiency,  reliability,  and  maintainability  of  software 

E systems.  The  most  widely  known  product  of  this  effort  is 

’ the  loosely  defined  set  of  design  and  programming  practices 

called  "Structured  Programming"  (see  references  1,  2,  and 

3). 

Structured  Programming  does  not  constitute  a complete 
software  development  methodology.  Rather,  it  is  a 
collection  of  general  guidelines  for  use  by  software 
designers  and  implementors.  As  such,  it  provides  no  uniform 
approach  to  system  design  and  offers  no  method  of  evaluating 
system  sufficiency  with  respect  to  requirements  or  design. 
Despite  these  shortcomings,  adherence  to  Structured 
Programming  principles  can  be  of  great  assistance  in 
producing  software  systems  which  are  reliable  and 
intellectually  manageable. 

The  techniques  of  Structured  Programming  are  sufficiently 
general  to  allow  system  developers  a tremendous  amount  of 
stylistic  freedom.  However,  the  generality  of  the 
techniques  has  made  the  development  of  a standard  approach 
to  software  analysis  extremely  difficult.  The  prototype 
JOVIAL  Structured  Design  Diagrammer  (JSDD)  is  the  first 
I component  of  an  integrated  software  analysis  and 

I documentation  system  which  will  address  itself  to  this  task. 

The  JSDD  is  an  automated  analysis  and  documentation  system 
which  produces  two  types  of  diagrams*  Structured  Design 
Diagrams  (SDDs)  and  Invocation  Diagrams.  SDDs  provide  a 
graphic  display  of  program  control  logic.  Invocation 

Diagrams  are  a display  of  a software  system's  functional 
(calling)  structure. 

The  JSDD  processes  digital  computer  programs  written  in 
either  JOVIAL  J3  or  Extended  JOVIAL  J3.  Extended  JOVIAL  J3 
is  standard  JOVIAL  J3  as  specified  in  reference  4 with  the 
addition  of  structured  extensions  (see  Section  6)  which  are 
based  upon  reference  5. 

The  symbology  employed  in  the  Structured  Design  Diagrams 
emerged  as  a result  of  research  at  Draper  Laboratory 
directed  toward  the  development  of  a software  system 
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specification  methodology.  This  symbology  is  inherently 
suited  to  portray  the  nested  logical  sequences  in  a modern 
structured  computer  language.  Because  the  symbology  is 
tailored  to  structured  programs,  its  utility  diminishes  when 
it  is  used  to  diagram  a program  that  makes  liberal  use  of 
Goto  statements  or  other  unstructured  language  constructs. 
Since  JOVIAL  J3  lacks  certain  structured  programii.ing 
mechanisms  which  eliminate  the  need  for  Goto  statements, 
these  mechanisms  have  been  added  as  allowable  programming 
features  In  programs  submitted  to  the  JSDD.  It  is  assumed 
that  such  programs  would  have  to  be  subjected  to  a 
preprocessor  before  submission  to  a JOVIAL  J3  compiler. 
Such  a preprocessor  has  been  supplied  as  a deliverable  item 
with  the  JSDD.  Sections  5 and  6 discuss  the  JOVIAL  J3 
syntax,  the  JOVIAL  J3  structured  extension  syntax,  and  the 
preprocessor. 


The  JSDD  is  implemented  in  JOVIAL  J3  as  a three  program 
system  that  is  designed  to  run  on  a Honeywell  Information 
Systems,  Inc.,  Series  6000  computer  supporting  GCOS  Version 
1/G,  The  Implementation  work  was  conducted  on  the  Home  Air 
Development  Center's  MULTICS  computing  facility  via  the  ARPA 
Network.  Development  work  was  performed  on  the  GCOS 
Encapsulator  which  is  available  under  the  MULTI CS  operating 
system.  The  MULTICS  environment  provided  most  of  the 
software  tools  that  were  employed  during  the  implementation. 
Appendix  A contains  a list  of  the  deliverable  items  produced 
under  this  contract. 


The  Final  Report  is  organized  as  followi 


Section  2 


discusses  the  use  of  Structured  Design  Diagrams  (SDDs); 
Section  3 describes  the  utility  of  Invocation  Diagraftisj 
Section  4 details  the  design  of  the  JSDD;  Section  S defines 
the  JOVIAL  J3  BNF  grammar;  Section  6 discusses  the 
structured  extensions  and  the  preprocessor;  and  Section  7 
contains  conclusions  and  recommendations  for  further  work. 


2.  Structured  Design  Diagram  Description 

Structured  Design  Diagrams  (SDDs)  provide  a graphic  two 
dimensional  display  of  the  nested  logical  sequences  that 
define  the  structure  of  a computer  program.  SDDs  for  JOVIAL 
J3  are  constructed  from  the  two  basic  structural  elements 
shown  in  figure  2-1. 


SEQUENTIAL  FLOW  DECISION  BRANCHING 


t-icure  2-1.  SDL  Frimitives 

The  rectangular  box  is  used  to  contain  elements  that  are 
executed  in  sequence.  Control  enters  from  the  top  or  left 
side  of  the  rectangle.  Each  element  in  a rectangle  is 
executed  in  sequence  and  control  flows  through  the  bottom  of 
the  box. 

The  pentagonal  box  is  used  to  contain  two  types  of  JOVIAL 
constructs*  module  heads  and  decision  making  elements.  A 
module  head  is  a <PHnGHA.M  MEAD>,  <PHOC  DESCRIPTOH>  or  <CLOSE 
HEAD>  (see  the  syntax  definition  of  JOVIAL  in  Section  5 ). 
Control  passes  through  the  bottom  of  a module  head's 
pentagonal  box  to  the  module's  code  body.  Figures  2-2,  2-3 
and  2-4  illustrate  SDD  representations  of  module  heads. 
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A decision  making  element  is  a JOVIAL  construct  which 
directs  the  flow  of  control  to  one  of  two  paths.  Evaluation 
of  the  contents  of  the  pentagonal  box  determines  the  path  to 
which  control  is  passed.  Figures  2-b,  2-6  2-7  and  2-b 
illustrate  the  SDl)  representaions  of  JOVIAL's  decision 
making  elements.  Non-standard  decision  making  elements  have 
been  introduced  as  structured  extensions  to  JOVIAL  J3.  The 
structured  extensions  are  the  Do  While  Loop,  the  Do  Until 
Loop  and  the  Case  Statement.  Full  descriptions  of  these  new 
constructs  are  available  in  Section  6. 


rioure  2-b.  oi.i;  representation  or  ttie  Ir  Statef’ent. 
Do  iinile  Loop  and  Do  until  Loop 
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LOOP  BODY 


fioure  2-o.  SLD  reoressnta t ion  of  tne  t-or  Loop 


rif.ure  , SIA)  representation  of  'che  Do  Case  btatement 


hinure  2-b.  SDD  representation  of  the  Alternative  Statemen 


Pentagonal  boxes  containing  decision  making  elements  are 
entered  from  the  top  or  from  the  left.  In  general,  they  are 
exited  by  taking  the  horizontal  path  (to  the  right)  or  by 
taking  the  vertical  path  (through  the  bottom  of  the 
pentagon).  The  horizontal  path  is  taken  if  the  decision 
element  is  evaluated  to  be  TRUE.  Otherwise,  the  vertical 
path  is  taken.  Note  that  the  SDD  representations  of  the  Do 
Case  Statement  and  Alternative  Statement  contain  "DO  CASE'^ 
and  -"IFEITH"  decision  making  elements.  These  elements  are 
always  evaluated  to  be  TRUE. 

If  a decision  making  element  is  evaluated  to  be  false  and 
its  pentagon  has  no  vertical  path,  then  the  SDD  execution 
path  must  retraced  until  a pentagon  is  found  which  has  an 
unexecuted  vertical  path.  If  such  a pentagon  is  found,  then 
the  vertical  path  must  be  followed.  If  no  such  pentagon  is 
found,  then  the  execution  of  the  module  has  been  completed. 

It  is  important  to  note  that  Goto  Statements  appear  in 
rectangular  boxes  and  their  effect  upon  a prograrn'^s  flow  of 
control  is  not  illustrated  by  an  SDD.  Restrained  usage  of 
the  Goto  statement  will  result  in  SDDs f which  will  better 
illustrate  a program's  flow  of  control.  The  structured 
extensions  to  JDVIAL  J3  (see  Section  6)  were  introduced  to 
minimize  the  JOVIAL  programmer's  reliance  upon  the  Goto 
Statement. 

Occasionally,  the  level  of  nesting  (of  decision  making 
elements)  in  a program  makes  it  impossible  to  display  a code 
block  in  the  available  number  of  page  columns.  In  such 
cases,  it  is  necessary  for  the  JSDD  to  create  what  is 
referred  to  as  a stump.  A stump  is  a diagram  continuation, 
rthen  the  width  of  a page  is  such  that  the  display  of  a code 
block  can  not  be  accommodated,  that  code  block's  logical 
position  in  the  SDD  is  filled  with  a stump  reference 
display.  The  stump  reference  display  consists  of  a stump 
reference  number  by  which  the  diagram  continuation  can  be 
located.  If  the  HEADING  option  is  on  (see  Section  5.2  of  the 
JSDD  User's  Manual),  then  the  stump  reference  number  is  the 
number  of  the  page  on  which  the  continuation  appears. 
Otherwise,  the  stump  reference  number  is  the  stump's 
sequence  number. 

The  JSDD  recognizes  three  types  of  comments*  in-line 
comments,  type-1  (or  same  line)  comments  and  type-2  (or 
C-type)  comments.  In-line  comments  are  comments  which  are 
embedded  in  a JOVIAL  statement.  In-line  comments  are 
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displayed  in  their  embedding  statements  in  SIX)s.  A type-1 
comment  is  a comment  which  begins  on  the  same  line  as  a 
JOVIAL  statement  in  the  input  file.  In  SDDs,  type-1  comments 
appear  below  the  statements  to  which  they  refer.  A type-2 
comment  is  a comment  which  appears  by  itself  in  the  input 
file.  SSDs  display  type-2  comments  next  to  the  line  which 
connects  the  code  blocks  which  precede  and  succeed  the 
coinment. 


Figure  2-y  is  a sample  page  from  a design  diagram  produced 
by  the  JSDD  system. 
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3.  Invocation  Diagram  Description 

The  Invocation  Diagrammer  produces  two  different  outputs* 
(I)  a list  of  procedures  that  are  members  of  one  or  more 
recursive  invocation  loops,  and  (2)  the  Invocation  Diagram 
itself. 

The  first  output,  if  it  appears  on  the  diagram,  occurs 
before  the  actual  diagram  under  the  heading  "ULTIMATELY 
SELF-RECURSIVE."  Under  It  are  listed  all  procedures  that 
call  themselves,  either  directly  or  indirectly.  An  example 
of  a direct  recursive  call  is  a procedure  which  contains,  as 
part  of  its  code,  a call  to  itself.  Indirectly  recursive 
calls  are  best  Illustrated,  again,  by  an  example.  Suppose 
procedure  A can  call  procedure  B which  can  call  procedure  C. 
If,  as  part  of  its  code,  procedure  C contains  a call  to 
procedure  A,  all  three  procedures  (A,  B,  and  C)  can 
theoretically  call  themselves. 

The  Invocation  Diagram  supplies  recursion  information  for 
two  reasons.  First,  the  diagrammer  has  to  detect  recursive 
procedures  because  its  algorithm  for  producing  the 
Invocation  Diagram  is  itself  recursive.  A recursive 
procedure  could  thus  cause  the  diagrammer  to  diagram 
forever.  Therefore,  recursive  procedures  are  only  expanded 
once  in  the  diagram,  and  thereafter  are  simply  printed  and 
flagged.  Since  this  affects  the  readability  of  the  diagram, 
the  recursion  information  ought  to  be  summarized  for  the 
user. 

Secondly,  it  can  be  argued  that  recursion  has  no  place  in 
JOVIAL  programs  (JOVIAL  J3  does  not  support  recursion),  and 
thus  should  be  banned.  The  recursion  information  can  be 
thought  of  as  a warning  to  the  programmer  that  illegal 
recursion  is  a possibility  in  the  submitted  program 
structure.  Note  that  the  Invocation  Diagrammer  only  reports 
the  po ssibility  of  recursion  - it  is  quite  possible  that  the 
program  in  question  avoids  actually  making  a recursive  call. 

The  second  output  is  the  Invocation  Diagram  itself.  The 
diagram  comes  in  two  parts*  a main  procedure  diagram  and 
diagrams  of  continuations  and  independent  routines.  The 
diagram  of  the  main  procedure,  if  it  occurs,  occurs  first. 
Invocation  Diagrams  are  quite  simple  to  read  - all  procedure 
names  which  are  connected  horizontally  to  a vertical  line 
are  called  by  the  procedure  whose  name  started  the  vertical 
line.  If  the  main  program  exists,  it  is  the  top  level  of 


the  diagram.  For  example! 
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In  this  example,  PROCI  calls  PR0C2,  PROC3,  and  PR0C5. 

Additionally,  we  see  that  PR0C3  calls  PR0C4,  and  some 
invisible  procedure  calls  PROCI.  That  procedure  is  at  the 
top  level  of  this  particular  diagram,  because  PROCI  hangs 
off  the  leftmost  vertical  line  possible.  There  is  still 
more  information  herei  we  know  PR0C2  is  an  external 
procedure  because  it  is  flagged  with  a "+•*,  PR0C5  is 
recursive  - it  is  flagged  with  a 

Main  diagram  continuations  (caused  by  running  off  the  right 
side  of  the  page)  and  independent  procedures  (procedures  not 
called  by  any  of  the  procedures  which  are  directly  or 
indirectly  called  by  the  main  program)  occur  at  the  end  of 
the  diagram,  under  the  heading  "CONTINUATIONS  AND 
INDEPENDENT  ROUTINES."  Continuations  consist  of  "stumps" 
which  correspond  to  similar  "stumps"  in  the  main  diagram. 

If  confronted  by* 

y 

in  the  main  program,  the  user  can  find  the  continuation  1 

below,  which  starts  with*  i 


y 

y 

etc. 

Stump  continuations  occur  in  numerical  order,  after 
independent  procedure  diagrams. 

The  aim  of  the  diagrammer  is  to  diagram  all  procedures. 
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regardless  of  whether  they  are  called  (directly  or 
Indirectly)  by  the  main  program*  However,  the  fact  that  a 
procedure  is  not  called  directly  or  indirectly  by  the  main 
program  is  not  a guarantee  that  it  will  appear  as  an 
^'independent"  procedure.  It  is  quite  possible  that  a second 
"independent"  procedure  whose  diagram  is  output  before  that 
of  the  first  procedure  may  call  the  first.  In  that  case, 
the  first  procedure's  "Independent"  diagram  is  suppressed. 
Nevertheless,  the  first  procedure's  diagram  will  have  been 
generated  as  part  of  the  second  procedure's  diagram.  No 
procedure  will  ever  remain  both  uncalled  and  undiagrammed. 


4.  Design  of  the  JOVIAL  StructtJred  Design  Diagrammer 

Figure  4-1  depicts  the  (conceptual)  two  pass  construction  of 
the  JSDD  systein.  "Pass  1“  (consisting  of  the  Design  Diagram 
Database  Generator)  performs  the  tasks  of  analyzing  the 
syntax  of  an  input  program  and  creating  a data  base  for  use 
by  the  second  pass.  "Pass  2"  (consisting  of  the  Design 
Diagram  Generator  and  the  Invocation  Diagrammer)  uses  the 
data  base  created  by  Pass  I to  construct  Structured  Design 
Diagrams  (SDDs)  and  Invocation  Diagrams.  A two  pass  design 
is  motivated  by  two  factors.  First,  it  is  desirable  to 
separate  language  dependent  functions  from  language 
independent  functions.  Such  a separation  facilitates  the 
adaptation  of  Pass  2 to  target  languages  other  than  JOVIAL 
J3.  Second,-  the  two  pass  design  provides  a great  deal  of 
flexibility  in  the  formatting  of  diagrams.  Pass  2 of  the 
JSDD  can  produce  diagrams  having  a wide  variety  of  formats 
from  the  data  base  produced  by  a single  Pass  1 execution. 


The  language  dependent  first  pass  uses  the  powerful  LALH(k) 
parsing  technique  formalized  by  DeRemer  (see  Reference  6) 
and  implemented  by  Lalonde  (see  Reference  7).  It  is  based 
on  the  compiler  structure  introduced  by  McKeeman,  et.  al. 
(see  reference  8). 

In  parsing  input  source  programs.  Pass  I acts  as  a 
table-driven  deterministic  pushdown  automaton  (DPDA).  The 
tables  which  drive  the  Pass  I parse  are  the  product  of  an 
LALR(k)  parser  generator  that  accepts  a syntactic 
description  of  a language  as  input  and  outputs  parsing 
tables  for  the  language  (see  Section  5). 

As  is  the  case  in  most  modern  compilers.  Pass  I generates 
output  as  the  result  of  a parser  decision  to  recognize  a 
high  level  programming  construct.  The  parser  is  guided  in 
this  decision  by  the  tables  described  above.  However, 
Instead  of  object  code,  which  is  what  a compiler  would 
ordinarily  produce.  Pass  I outputs  a diagramming  data  base 
to  be  used  by  Pass  2. 

The  two  Pass  2 programs  (the  Design  Diagram  Generator  (DDG) 
and  Invocation  Diagrainirier ) interpret  the  Pass  I generated 
data  base,  and  create  diagrams  in  accordance  with  the 
formatting  specifications  in  the  DDG  options  compool  (see 
User's  Manual).  The  DDG  is  implemented  as  a two  part 
program.  First  it  maps  out  the  Structured  Design  Diagram 
and  creates  a temporary  data  base  containing  the  mapping 
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XIVIALJS  SOURCE 

WITH  OR  WITHOUT  * 

STRUCTURED  EXTENSIONS 

DESIGN  DIAGRAM  DATA 
BASE  GENERATOR  (DDDG) 
SCAN  AND  PARSE 


PARSE  TABLES 


INVOCATION 

DIAGRAMMER 


DESIGN  DIAGRAM 
GENERATOR  (DOG) 
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DIAGRAMS 


STRUCTURED 
DESIGN  DIAGRAMS 


rigure  4-1.  Two-Pass  Construction  of  the  JSDD 


Information.  Only  then  does  It  produce  the  actual  diagram. 
This  strateoy  allows  It  to  calculate  forward  and  backward 
referencing  Information  (In  case  a diagram  overflows  the 
page  width)  and  a Table  of  Contents,  without  committing 
prematurely  to  any  hard-copy  output.  If  adjustments  need  to 
be  made  In  the  diagram,  the  temporary  data  base  can  be 
modified  easily. 

The  Invocation  Dlagrammer  uses  a simple  recursive  strategy 
to  create  the  Invocation  Diagram.  As  the  first  procedure 
name  Is  written  out,  the  next  procedure  it  calls  is  written 
beneath  and  to  the  right  of  It.  The  Information  for  the 
first  procedure  Is  stacked,  and  the  new  procedure  Is  treated 
as  though  It  were  the  first.  When  no  procedures  are  called 
by  the  current  rightmost  procedure  name,  the  stack  is  popped 
back  and  the  next  rightmost  procedure  name  is  written  out. 
When  no  more  procedures  are  on  the  stack,  the  diagram  is 
complete. 


The  Invocation  Dlagrammer  and  DDG  have  been  implemented 
separate  programs  to  enhance  system  maintainability. 


as 


5.  Defining  the  JOVIAL  J3  Syntax 

The  syntactic  analysis  of  JOVIAL  J3  source  programs  is 
performed  by  a table  driven  parser  In  Phase  I of  the  JSOD. 

The  tables  are  generated  by  an  LALR(lc)  parser  generator.  The 
parser  generator  accepts  the  syntactic  description  of  a 
language  (In  BACKUS-NAUR  form)  and  produces  the  parsing 
tables  for  the  language. 

The  parser  generator  can  produce  tables  for  any  LALR(k) 
gratnmar  where  k Is  finite. 

A (context-free)  grammar  can  be  defined  loosely  as  an 
alphabet  and  a set  of  productions  of  the  formi 

A *1=  xy 

where  A,  x and  y are  members  of  the  alphabet  (the  alphabet 
is  the  set  of  all  symbols  used  to  define  the  syntax  of  a 
language).  The  phrase  "can  be  replaced  by"  can  be 
substituted  for  the  symbol  **=.  Members  of  the  alphabet 
which  appear  on  the  left  hand  sides  of  productions  are 
called  non-terminals  and  those  that  appear  on  only  the  right 
hand  sides  of  productions  are  called  terminals.  In  the  set 
of  non-terminals,  there  is  one  designated  symbol  called  the 

goal  symbol  (in  the  case  of  JOVIAL  J3''s  grammar,  the  goal 

symbol  is  <PROGRAM>). 

A sentence  is  defined  to  be  a string  of  terminal  symbols 
generated  by  the  grammar.  A sentence  can  be  generated  by 
starting  with  the  goal  symbol  and  then,  continually 
replacing  each  nonterminal  with  its  definition  (l.e.,  its 
right  hand  side)  until  no  nonterminals  appear  in  the  string. 
The  resulting  string  is  a sentence. 

The  sequence  of  replacements  Involved  in  generating  a 

sentence  can  be  represented  by  a tree  (called  the  parse 

tree)  which  is  unique  for  each  sentence  generated  by  an 
unambiguous  grammar. 

There  is  no  grammar  processable  by  a left  to  right  parser 
generator  (having  an  finite  upper  bound  on  required 
lookahead)  which  generates  all  JOVIAL  J3  programs  and  which 
generates  no  sentences  which  are  not  JOVIAL  J3  programs. 

Consider  the  following  JOVIAL  J3  subgrammar* 


I 


<PROCEDURE  CALL>  «i=  <IDENTIFER>  ( <FQRMULA>  ) $ 
<FORMULA>  11=  <BOOLEAN  FORMULA> 

: <NUMERIC  FORMUU> 

! <ENTRY  FQRMULA> 

<BOOLEAN  FORMULA>  tis  o 
<NUMERIC  FORMULA>  tt«  0 
<ENTRY  FORMULA>  »i=  0 

The  sentence! 

PROC'NAME  (0)  $ 

has  three  distinct  parse  trees.  They  are  shown  below. 
I)  <PROCEDURE  CALL> 


<IDENTIFIER> 


( <FORMULA> 


<BODLEAN  FORMULA> 


<PROCEDURE  CALL> 


<IDENTIFIER> 


( <FORMULA> 


<NUMERIC  FORMULA> 


<PROCEDURE  CALL> 


<IDENTIFIER> 


( <FORMULA>  ) 


<ENTRY  FORMULA> 


In  order  to  sidestep  this  problem  (and  several  other  similar 
problems }«  the  JOVIAL  J3  grammar  has  been  '■'expanded'^  so 
that  all  JOVIAL  J3  programs  can  be  parsed.  However,  as  a 
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result  of  this  expansion,  there  are  sentences  which  the 
grammar  can  generate  which  are  not  valid  JOVIAL  J3  programs. 


The  solution  which  has  been  adopted  to  the  problem  described 
above  is  to  thread  all  of  the  formulae  together.  That  is, 
redefine  the  grammar  in  this  fashion* 


<PROCEDURE  CALL>  *i=  <IDENTIFIER>  ( <FORMULA>  ) $ 
<FORMULA>  «i=  <BOOLEAN  FORMULA> 

<BOOLEAN  FORMULA>  **=  <ENTRY  FORMUi.A> 

<ENTRY  FQRMULA>  *1=  <NUMERIC  FORMULA> 

<NUMER1C  FORMULA>  **=  0 


The  obvious  drawback  to  this  redefinition  is  that  every 
<NUMERIC  FORMULA>  can  be  accepted  as  an  <ENTRY  FORMULA>  and 
as  a <BCXDLEAN  FORMULA>  (and  so  on).  The  advantage  is  that  it 
will  avoid  an  ambiguity  in  the  grammar  and  allow  the  parser 
generator  to  produce  parsing  tables.  (Many  modern  languages 
such  as  XPL  and  ALGOL  use  an  approach  similar  to  this  in 
their  syntax  definitions.) 

The  syntax  of  JOVIAL  J3  is  relatively  complex  for  a 
progra;»inlng  language.  This  complexity  requires  that  JOVIAL's 
BNF  description  contain  a very  large  number  of  productions. 
In  attempting  to  generate  parsing  tables,  it  was  found  that 
the  size  of  JOVIAL's  BNF  description  exceeded  an  internal 
limit  Imposed  upon  the  parser  generator-'s  input  grammars.  In 
order  to  avoid  a costly  investigation  of  the  parser 
generator-'s  limits,  work  on  the  JSDD  was  based  on  an  early, 
slightly  Inaccurate  version  of  the  JOVIAL  grammar.  The 
Design  Diagrammer  Data  Base  Generator  has  been  adjusted  to 
enable  it  to  successfully  parse  the  full  set  of  valid  JOVIAL 
programs. 


The  JOVIAL  J3  grammar  used  by  the  JSDD  is  presented  below. 


1 <PROGRAM>  »*=  <PROGRAM  HEAD>  <ELEMENT  LIST> 

\ <PROGRAM  TAIL> 


2 

3 

4 

5 
5 


<PROGRAM  HEAD>  ii=  START  $ 

! CLOSE  <IDENTIFIER>  $ START  $ 
! START  PROC  <IDENTIFIER>  $ 

; START  PROC  <IDENTIFIER> 

< FORMAL  PARAMETER  LIST>  $ 


6 <PROGRAM  TAIL>  i*=  TERM  $ 


! TERM  <IDENTIFIER>  $ 


<ELEMENT  LIST>  »*=  <ELEMENT> 

i <ELEMENT  LIST>  <ELEMENT> 

<ELEMENT>  ii=  <STATEMENT> 

S <DECLARATION> 

: <DI RECTI VE> 

<DI RECTI VE>  «»=  <DEFINE  DIRECTIVE> 

: <MODE  DIRECTIVE> 

<DEFINE  DIRECTIVE>  ti=  <DEFINE  HEAD>  <TEXT>  ■'''  $ 

<DEFINE  HEAD>  **=  DEFINE  <IDENTIFIER> 

<-^y>  Its 


<TEXT>  *1=  <CHARACTERS> 

{ <TEXT>  <CHARACTERS> 

<MODE  DI RECTI VE>  ii=  MODE  <ITEM  DESCRIPTIONv  $ 

; MODE  <ITEM  DESCRIPTION>  P 
<CONSTANT>  $ 

<STATEMENT>  ii=  ^SIMPLE  STATEMENT> 

! <LABEL>  <SIMPLE  STATEMENT> 

! <COMPLEX  STATEMENT> 

: <LABEL>  <COMPLEX  STATEMENT> 

{ <COMPOUND  STATEMENT> 

! <LABEL>  <COMPOUND  STATEMENT> 

<LABEL>  *1=  <IDENTIFIER>  . 

: <LABEL>  <IDENTIFIER>  . 

<DECLARATION>  ii=  <DATA  DECLARATION> 

I <PRaCESSING  DECLARATION> 

<PROCESSING  DECLARATION>  *i=  <SWITCH  DECLARATION> 

! <PROGRAM  DECLARATIQN> 

! <CLOSE  DECLAHATION> 

: <PROCEDURE  DECLARATION> 
I <COMMON  DECLARATION> 

<COMMON  DECLARATION>  »*=  <COMMON  HEAD> 

<COMPOUND  STATEMENT> 


<COMMON  HEAD>  »t=  COMMON  <IDENTIFIER>  $ 

! COMMON  $ 

<SWITCH  DECLARATION>  »»=  <SWITCH  HEAD>  <ITEM  TAIL> 

! <SWITCH  HEAD>  <INDEX  TAIL> 

<SWITCH  HEAD>  i»*  SWITCH  <IDENTIFIER> 

<ITEM  TAIL>  *1=  ( <IDENTIFIER>  ) = ( <ITEM  LIST>  ) $ 

<ITEM  LIST>  11=  <CONSTANT>  = <GOTO  FORMULA> 

! <ITEM  LIST>  , <CONSTANT>  = 

<GOTO  FORMULA> 

<CONSTANT>  »*=  <LITERAL  CONSTANT> 

I <STATUS  CONSTANT> 

: <NUMERIC  CONSTANT> 

<INDEX  TAIL>  *1=  ^ ( ) $ 

I = ( <GOTO  LIST>  ) $ 

<GOTO  LIST>  **=  <GOTO  FORMULA> 

5 <GOTO  LIST>  , <GOTO  FORMULA> 

I 

i <GOTO  LIST>  , 

<GOTO  FORMULA>  ii=  <IDENTIFIER> 

I <IDENTIFIER>  ($  <INDEX  LIST>  $) 

<PROGRAM  DECLAHATION>  ii=  PROGRAM  <IDENTIFIER>  $ 

<CLOSE  DECLARATION>  ti=  <CLOSE  HEAD> 

<COMPOUND  STATEMENT> 

<CLOSE  HEAD>  »*=  CLOSE  <IDENTIFIER>  $ 

<PROCEDURE  DECLARATION>  **=  <BLOCK  HEAD> 

<COMPOUND  STATEMENT> 

<BLOCK  HEAD>  ii=  <PROC  DESCRIPTOR> 

1 <BLOCK  HEAD>  <DI RECTI VE> 

! <BLOCK  HEAD>  <DATA  DECLARATION> 

! <BLOCK  HEAD>  <PROGRAM  DECLARATION> 


<PROC  DESCRIPTOR>  ii=  <PROC  HEAD>  $ 

: <PROC  HEAD> 

<FORMAL  PARAMETER  LIST>  $ 
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67  <PROC  HEAD>  ti-=  PROC  <IDENTIFIER> 


68  <FORMAL  PARAMETER  LIST>  t*=  ( ) 

69  : ( < parameter  LIST>  ) 

70  ! ( < PARAMETER  LIST>  = 

70  <PARAMETER  LIST>  ) 

71  : ( = < PARAMETER  LIST>  ) 


72  <PARAMETER  LIST>  tt=  <IDENTIFIER> 

73  ! <PARAMETER  LIST>  , <IDENTIFIER> 

74  : <IDENTIFIER>  . 

75  ! <PARAMETER  LIST>  , <IDENTIFIER>  . 


76  <COMPOUND  STATEMENT>  i*=  <BEGIN>  <END> 

77  I <BEGIN>  <ELEMENT  LIST>  <END> 

78  <CONSTANT  LIST>  tt=  <CONSTANT> 

79  ! <CONSTANT  LIST>  <CONSTANT> 

80  <COMPLEX  STATEMENT>  it=  <CONDITIONAL  STATEMENT> 

81  I <ALTERNATIVE  STATEMENT> 

82  I <LOOP  STATEMENT> 

83  ! <DIRECT  STATEMENT> 

84  ; <STRUCTURED  EXTENSION> 

85  <CONDITIONAL  STATEMENT>  **=  <IF  CLAUSE>  <THEN  CLAUSE> 


86  <ALTERNATIVE  STATEMENT>  ti=  <IFEITH  CLAUSE> 

86  <THEN  CLAUSE>  <ALT  LIST> 

86  <END> 


87  <IF  CLAUSE>  ii=  IF  <BCIOLEAN  FORMULA>  $ 

88  <THEN  CLAUSE>  ii=  <SIMPLE  STATEMENT> 

89  ! <COMPOUND  STATEMENT> 

90  <IFEITH  CLAUSE>  i»=  <IFEITH>  <BOOLEAN  FORMULA>  $ 

91  <IFEITH>  11=  IFEITH 


92  <ALT  LIST>  it=  <ORIF  PART> 

93  ! <ALT  LIST>  <ORIF  PART> 

94  <ORIF  PART>  it=  <ORIF  CLAUSE>  <THEN  CLAUSE> 

95  <ORIF  CLAUSE>  ii=  ORIF  <BOOLEAN  FQRMULA>  $ 


2b 
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: <LABEL>  ORIF  <BOOLEAN  FDRMULA>  $ 


97  <LOOP  STATEMENT>  t»=  <COMPLETE  LOOP> 

98  ! < INCOMPLETE  LOOP> 

99  <INCOMPLETE  LOOP>  ti=  < INCOMPLETE  FOR> 

99  < INCOMPLETE  BODY> 

JOO  < INCOMPLETE  FOR>  i*=  <1  FACTOR  FOR  CLAUSE> 

101  ; <2  FACTOR  FOR  CLAUSE> 

102  <2  FACTOR  FOR  CLAUSE>  *»=  FOR  <LOOP  COUNTER>  » 

102  <2  INDEX  LIST>  $ 

103  <2  INDEX  LIST>  » »=  <NUMERIC  FORMULA>  , 

103  <NUMERIC  FORMULA> 

104  <1  FACTOR  FOR  CLAUSE>  **=  FOR  <LOOP  COUNTER>  = 

104  <NUMERIC  FORMULA>  $ 

105  <INCOMPLETE  BODY>  »»=  <SIMPLE  STATEMENT> 

106  I <COMPOUND  STATEMENT> 

107  I <SPECIAL  COMPOUND  STATEMENT> 

108  : <LABEL> 

108  <SPECIAL  COMPOUND  STATEMENT> 


109 

<COMPLETE  LOOP>  ii=  <FOR  CLAUSE>  <COMPLETE 

BODY> 

no 

1 1 1 

<FOR  CLAUSE>  ii=  <l  FACTOR  PART>  <3  FACTOR 
! <3  FACTOR  FOR  CLAUSE > 

FOR  CLAUSE> 

1 12 
112 

<3 

FACTOR  FOR  CLAUSE>  tt=  FOR  <LOOP  COUNTER>  = 

<3  INDEX  LIST>  $ 

113 

114 
114 

<1 

FACTOR  PART>  ii=  <1  FACTOR  FOR  CLAUSE> 

1 <1  FACTOR  PART> 

<1  FACTOR  FOR  CLAUSE > 

115 

115 

115 

<3 

INDEX  LIST>  11=  <NUMERIC  FORMULA>  , 
<NUMERIC  FORMULA>  , 
<NUMERIC  FORMULA> 

116  <COMPLETE  BODY>  ii=  <INCOMPLETE  BODY> 

117  ! < INCOMPLETE  LOOP> 

118  <SPECIAL  COMPOUND  STATEMENT>  i*=  <BEGIN> 

118  <SPECIAL  PART>  <END> 
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! <BEGIN> 

<ELEMENT  LIST> 
<SPECIAL  PART>  <END> 

<SPECIAL  PART>  »i=  IF  ^BOOLEAN  FDRMULA>  $ 

! <LABEL>  IF  <BaOLEAN  FORMUU>  $ 

<STRUCTURED  EXTENSION>  *i=  <DO  STATEMENT> 

! <CASE  STATEMENT> 

<DO  STATEMENT>  »«*  <DO  HEAD>  <ELEMENT  LIST>  <END  DO> 

<DO  HEAD>  »»■=  DO  WHILE  ( <BOOLEAN  FORMULA>  ) 

! DO  UNTIL  ( <BOOLEAN  FORMULA>  ) 

<END  DO>  11=  END  DO 

<CASE  STATEMENT>  »*=  <CASE  HEAD>  <CASE  LIST> 

<END  CASE> 

<CASE  HEAD>  i«=  DO  CASE  ( <NUMERIC  FORMULA>  ) 

<CASE  LIST>  i»=  <CASE> 

; <CASE  LIST>  <CASE> 

<CASE>  i»=  <INSTANCE>  <ELEMENT  LIST> 
t <INSTANCE> 

<INSTANCE>  11=  ( <NUMBER>  ) 

<END  CASE>  i»=  END  CASE 

<SIMPLE  STATEMENTS  ti=  <ASSIGNMENT  STATEMENT> 

I <EXCHANGE  STATEMENT> 

I <GOTO  STATEMENT> 

5 <RETURN  STATEMENT> 

! <STOP  STATEMENT> 

: <PROCEDURE  CALL> 

! <10  STATEMENT> 

: <TEST  STATEMENT> 

<TEST  STATEMENT>  ii=  TEST  $ 

! TEST  <LOOP  COUNTER>  $ 

<10  STATEMENT>  ii«  <ACTION>  <MODE>  <IDENTIFIER> 

<DATA  LIST>  $ 

5 <ACTION>  <MODE>  <IDENTIFIER>  $ 


5 <MODE>  <IDENTIFIER>  <DATA  LIST>  $ 

<ACTION>  ii«  OPEN 
; SHUT 

<MODE>  *1*  INPUT 
I OUTPUT 

<DATA  LIST>  11=  <FORMULA> 

{ <IDENTIFIER>  <RANGE> 

! <DATA  LIST>  , <FORMULA> 

: <DATA  LIST>  , <IDENTIFIER>  <RANGE> 

<RANGE>  ($  <NUMERIC  FORMULA>  <RANGE  CLOSE> 

<RANGE  CLOSE>  ii=  ...  <NUMERIC  FDRMULA>  $) 

<DIRECT  STATEMENT>  *i=  <DIRECT>  <TEXT>  JOVIAL 

<DIRECT>  *1=  DIRECT 

<ASSIGNMENT  STATEMENT>  i»=  <VARIABLE>  = <FORMULA>  $ 

<EXCHANGE  STATEMENT>  »»=  <VARIABLE>  = <VARIABLE>  $ 

<GOTO  STATEMENT>  *t=  GOTO  <GOTO  FORMULA>  $ 

<RETURN  STATEMENT>  »i=  RETURN  $ 

<STOP  STATEMENT>  i»=  STOP  $ 

: STOP  <IDENTIFIER>  $ 

<PROCEDURE  CALL>  i*=  <PROC  NAME>  $ 

! <PROC  NAME> 

< ACTUAL  PARAMETER  LIST>  $ 

<p'rOC  NAME>  11=  <IDENTIFIER> 

<ACTUAL  PARAMETER  LIST>  ii=  ( ) 

! ( < ACTUAL  LIST>  ) 

! ( < ACTUAL  LIST>  = 

< ACTUAL  LIST>  ) 

: ( = < ACTUAL  LIST>  ) 


<ACTUAL  LIST>  ti»  <FORMUU> 

: <IDENTIFIER>  . 

I < ACTUAL  LIST>  , <FORMULA> 
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00  00  >>J 


<DATA  DECLARATI0N>  »i=  <SIMPLE  ITEM  DECLAHATIQN> 

; <ARRAY  DECLARATI0N> 

: <TABLE  DECLARATION> 

S <0VERLAY  DECLARATiaN> 

I <FILE  DECLARATION> 

J <MONrfOR  DECLAHATIOin|> 


<MONITOR  DECLARATiaN>  **=  MONITOR  <PARAMETtR  LIST>  $ 

; MONITOR  ( <BOOLEAN  FOHMULA> 
) <PARAMHTEH  LISr>  S 


<FILE  DECLARATION>  i*=  <FILE  HEAD>  <FILE  TAIL>  $ 


<FILE  HEAD>  ii*  FILE  <IL>ENTIFIER> 


<FILE  TAIL>  »i=  <F  TYPE>  <NUMBtR>  <RHC  OHO  <NUMBER> 
<NUMBER> 

! <F  TYPE>  <NUMBtR>  <REC  OHO  <NUMBEH> 
<STATUS  LIST>  <NUMBEH> 


<F  TYPE>  *1=  H 
: B 


<HEC  0RG>  11=  V 
: R 


<STATUS  LIST>  i*=  <STATUS  C0NSTANT> 

! <STATUS  LIST>  <STATUS  C0NSTANT> 


<SIMPLE  ITEM  UECLAHATI0N>  ii=  ITEM  <IDENTIFIEH> 

<ITEM  DESCHIPTION>  $ 
; ITEM  <IDENTIFIER> 
<ITEM  DESCHIPTION>  P 
<C0NSTANT>  $ 

; ITEM  <IU£NTIFIER> 
<C0NSTANT>  $ 


<ITEM  DESCHIPTI0N>  ii=  <INTEGEH  DESCHIPTION> 

I <FIXEU  DESCHIPTION> 

! <FLOATING  DESCHIPTION> 
! <LITERAL  DESCHIPTION> 

I <STATUS  DESCRIPTION> 

! <BOOLhAN  D£SCRIPTION> 


: <ACTUAL  LIST>  , <IDENTIFIEH>  . 


6 <INTEGER  DESCHIP'nON>  ii=  <INT  HEAU> 


206 

207 

208 


! <INT  HEAD>  <INT  TAIL> 

: <FIXED  HhAD> 

J <H1XHU  HEAD>  <INT  TAIL> 


<INT  MfcAD>  *1=  I <SIGNING> 

<FIXt:L)  HHAD>  *i=  A <NU//lBbl-{>  <SIGNING> 


<SIGNING>  *»=  U 


<INT  TAIL>  **=  R 

: <INTEGEK>  ...  <Ii'iTEGER> 

! R <INTEGER>  ...  <INi’EGER> 

<FIXEL)  DESCRIRTI0N>  **=  <FIXED  HEAU>  <t-RAC  bITS> 

! <FIXED  HEAD>  <FRAC  UITS> 
<RIGHT  PAHT> 

<FHAC  BITS>  *:=  <NUMBER> 

! <ADD  QP>  <NUMBER> 

<HIGHT  PART>  *»=  R 

: R <NUMERIC  GaNSTANT>  ... 

<NUMERIC  C0NSTANT> 

: <NUMERIC  C0NSTANT>  ... 

<NUMEHIC  C0NSTANT> 

<FL0ATING  DESCRIPriUN>  i*=  F 

! F R 

<LITERAL  l)ESCRIPTIUN>  j*=  H <NUMBER> 

! T <NUMBER> 

<STATUS  DESCRIPTIGiM>  ii=  S <STATUS  LIST> 

! S <NUMBER>  <STATUS  LIST> 

<B00Lc'AN  l)ESCRIPTIGN>  »:=  B 

<ARRAY  UECLARAnDU>  **=  <ARRAY  UESCRIPTI0N> 

<INn  LIST> 

: <AHRAY  DESCRIPTI0N> 

<ARRAY  DESCRlPTIGiM>  :*=  <ARRAY  HEAU> 

<ITEM  UESCRIPTI0N>  $ 

<ARRAY  HEA0>  ii=  ARRAY  <IDENTIFIER>  <0IM  LIST> 


234 

235 


236 

237 


238 

239 


240 

241 

242 


243 

243 


244 

245 


246 

247 

248 

249 
249 


250 

251 

252 


253 

253 

254 
254 
254 


255 

256 


257 

258 


259 

260 
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<INIT  LIST>  i»=  <BEGINI>  <C0NSTANT  LIST>  END 
\ <BEGINI>  <INIT  SUB  LIST>  END 


<INIT  SUB  LIST>  11=  <INIT  LIST> 

: <INIT  SUB  LIST>  <INIT  LIST> 


<DIM  LIST>  11=  <NUMBER> 

! <DIM  LIST>  <NUMBER> 


<TABLE  DECLARATI0N>  **=  <0RDINARY  TABLE  DEC> 

: <DEF  TABLE  DEC> 

I <LIKE  TABLE  DEO 


<0RDINARY  TABLE  DEO  *t=  <0RD  HEAD>  <BEGIN2> 

<0RD  ENTS>  <END2> 


<0RD  HEAD>  i»=  <TABLE  HEAD>  $ 

I <TABLE  HEAD>  <PACKING>  $ 


<TABLE  HEAD>  it=  TABLE  <TABLE  SIZE> 

TABLE,  <IDENTIFIER>  <TABLE  SIZE> 

! TABLE  <TABLE  SIZE>  <TABLE  STRUCTUHE> 
I TABLE  <IDENTIFIER>  <TABLE  SIZE> 
<TABLE  STRUCTURE> 


<0RD  ENTS>  »*=  <ENTHY  ITEM  DEC> 

t <0RD  ENTS>  <ENTHY  ITEM  DEC> 

! <0RD  ENTS>  <SUB0RDINATE  OVERLAY  DEC> 


<ENTfiY  ITEM  DEC>  »i=  ITEM  <IDENTIFIER> 

<ITEM  DESCRIPTI0N>  $ 

; ITEM  <IDENTIFIER> 

<ITEM  DESCHIPTI0N>  $ BEGIN 
<C0NSTANT  LIST>  END 


<TABLE  SIZE>  ii=  V <NUMBER> 
; R <NUMBER> 


<TABLE  STRUCTURE>  **=  P 

I S 


<PACKING>  11=  N 
! M 
! D 


262  <DEF  TABLE  DEO  ii=  <DEF  HEAD>  <BEGIN2>  <DEF  ENTS> 
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262 


<END2> 


263  <DEF  HEAD>  l i»  <TABLE  HEAD>  <NUMBEH>  S 


264 

265 

266 

267 

268 

269 

270 

270 

271 

271 

272 
272 

272 

273 

273 

274 

274 
276 

275 

276 

276 

277 
2 77 


<DEF  ENTS>  ii« 


<DEF  ITEM  DEC> 


<DEF  ITEM  DEC> 

<STRING  ITEM  DEC> 

<DEF  ENTS>  <DEF  ITEM  DEC> 

<nEF  ENTS>  <STRING  ITEM  DEC> 

11=  <DEF  ITEM  HEAD>  $ 

S <DEF  ITEM  HEAD>  <PACKING>  $ 

! <DEF  ITEM  HEAD>  $ BEGIN 
<C0NSTANT  LIST>  END 
! <DEF  ITEM  HEAD>  <PACKING>  $ BEGIN 
<C0NSTANT  LIST>  END 


<DEF  ITEM  HEAD>  ii  = 


<STRING  ITEM  DEC>  tt. 


<STRING  HEAD>  ii  = 


ITEM  <IDENTIFIER> 

<ITEM  DESCRIPTI0N>  <NUMBER> 
<NUMBER> 

<STRING  HEAD>  <NUMBER>  <NUMBER> 

$ 

<STRING  HEAD>  <PACKING>  <NUMBER> 
<NUMBER>  $ 

<STRING  HEAD>  <NUMBEH>  <NUMBER> 

$ <2  DIM  CONSTANT  LIST> 

<STRING  HEAD>  <PACKING>  <NUMBER> 
<NUMBER>  $ <2  DIM  CONSTANT  LIST> 


STRING  <IDENTIFIER> 
<ITEM  DESCRIPTION> 


278  <2  DIM  CONSTANT  LIST>  »i=  BEGIN  <COMPONENT  LIST>  END 


279  <COMPONENT  LIST>  i»=  BEGIN  <CONSTANT  LIST>  END 

280  I <CDMPONENT  LIST>  BEGIN 

280  ^CONSTANT  LIST>  END 

281  <LIKE  TABLE  DEC>  ii=  <TABLE  HEAD>  L $ 

282  : <TABLE  HEAD>  <PACKING>  L $ 

283  <OVERLAY  DECLARATION>  ii=  <INDEPENDENT  OVERLAY  DEC> 

284  : <SUBORDINATE  OVERLAY  DEC> 

285  <INDEPENDENT  OVERLAY  DEC>  n=  OVERLAY  <ORIGIN> 

285  <OVERLAY  TAIL> 
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tJ  Uj  Ui  (*)  U)  U)  CJ  (a)  Ca>  CJ  CjOjCJ  INJfVJ  N>MIVJ  t\i  N>  N)  IVJ IVJ  M IVJ  M lU  N) 

— OOOCO  OOOO  OOQ  'O'O  « <0  « 'O  'C'O  'O'O  003  05  00  QP 

O'OOO^^tJi  AAU)(a)  M — O <000  •g-JO  tJ  N>—  5 ■>IO> 


<0RIGIN>  tt»  <NUMBER> 


! <0CTAL  C0NSTANT> 

<SUBORDINATE  OVERLAY  DEO  ii=  OVERLAY  <0VERLAY  TAIL> 

<0VERLAY  TAIL>  i i=  <IDENTIFIER  LIST>  $ 

5 <IDENTIFIER  LIST>  <0VERLAY  LIST>  $ 

<IDENTIFIER  LIST>  ii=  <IDENTIFIER> 

! <IDENTIFIER  LIST>  , <IDENTIFIER5 

<0VERLAY  LIST>  »i=  = <IDENTIFIER  LIST> 

! <0VERLAY  LIST>  = <IDENTIFIER  LIST> 

<F0RMULA>  II*  <B00LEAN  F0RMULA> 

<B00LEAN  F0RMULA>  ii=  <B00LEAN  TERM> 

1 <B00LEAN  F0RMULA>  OR 
<B00LEAN  TERM> 

<B00LEAN  TERM>  ii=  <B00LEAN  PRIME> 

: <BOOLEAN  TERM>  AND  <B00LEAN  PRIME> 

<B00LEAN  PRIME>  n*  <LITERAL  F0RMULA> 

; NOT  ( <bOOLEAN  PH I ME > ) 

! <RELATIONAL  EXPRESS  ION > 

<RELATIONAL  EXPRESSION>  n*  <LITERAL  F0RMULA>  <REL  0P> 

<LITERAL  F0RMULA> 

: <RELATIONAL  EX PRESS I ON > 
<REL  0P>  <LITERAL  F0RMULA> 

<REL  0P>  II*  EO 
: NO 
: GR 
! GQ 
: LS 
: LQ 

311  <LITERAL  F0RMULA>  ii»  <STATUS  F0RMULA> 

312  ! <LITERAL  C0NSTANT> 

313  <LITERAL  C0NSTANT>  ii»  <LITERAL  HEAD>  ( <CHARACTERS>  ) 

314  <LITERAL  HEAD>  ii*  <NUMBER>  H 

315  ! <NUMBEH>  T 


I 


I 
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316 

317 

318 

319 

320 

321 

322 

323 

324 

325 

326 

327 

328 

329 

330 

331 

332 

333 

334 

335 

336 

337 

338 

339 

340 

341 

342 

343 

344 

345 

346 

347 

348 


<STATUS  F0RMULA>  *»*  <STATUS  C0NSTANT> 

! <NUMERIC  H0RMULA> 

<STATUS  C0NSTANT>  *i»  <STATUS  HEAD>  <CHARACTERS>  ) 

<STATUS  HEAD>  **=  V ( 

<NUMERIC  F0RMULA>  ii=  <EXPRESSI0N> 

<EXPRESSIQN>  11=  <EXPRESSIQN>  <ADD  0P>  <TERM> 

; <TERM> 

<TERM>  11=  <TERM>  <MULT  □P>  <FACT0R> 

: < FACTOR > 

<FACTaR>  »»=  <PHIME>  ★*  <FACTOR> 

1 <PRIME>  (*  <FACTDR>  *) 

! <ADD  □P>  <PRIME> 

1 <PRIME> 

<PRIME>  i*=  <VARIABLE> 

I <FUNCTION> 

! <NUMERIC  CONSTANT> 

; ( <BOOLEAN  FORMULA>  ) 

I (/  <NUMERIC  FORMULA>  /) 

<FUNCTION>  *1=  <IDENTIFIER>  ( ) 

; <IDENTIFIER>  ( <ACTUAL  LIST>  ) 

<ADD  0P>  »*=  + 

• _ 

<MULT  □P>  11=  * 

I / 

<NUMERIC  CaNSTANT>  »*=  <INTEGER> 

! <FLOATING  CONSTANT> 

I <FIXED  CONSTANT> 

! <OCTAL  CONSTANT> 

<INTEGER>  11=  <NUMBER> 

: <NUMBER>  E <NUMBER> 

<FLOATING  CONSTANT>  ii=  <MANTISSA> 

: <MANTISSA>  <CHARACTERISTIC> 

<CHARACTERISTIC>  it=  E <NUMBER> 
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349 


; E <ADD  0P>  <NUMbER> 


f 350 

<FIXED  C0NSTANT> 

11=  <FLDATING  CONSTANT>  A <NUMBER> 

f 351 

1 <FLOATING  CONSTANTS  A <ADD  0P> 

1 351 

<NUM8ER> 

! 352 

1 

<0CTAL  C0NSTANT> 

lt=  0 ( <NUMBEH>  ) 

i 353 

<VARIABLE>  *1=  <IDENTIHIER> 

354 

: <LOOP  C0UNTER> 

355 

: <IDENTIFIER>  ($  <INDEX  LIST>  $) 

? 356 

! <M0DIFIED  VARIAaLE> 

' 357 

<INDEX  LIST>  M=  <NUMERIC  F0RMULA> 

358 

! <INDEX  LIST>  , <NUMEHIG  F0RMULA> 

359 

<LCX3P  C0UNTER>  *t: 

= A 

360 

B 

361 

C 

362 

D 

363 

E 

364 

F 

365 

G 

366 

H 

367 

I 

368 

J 

369 

K 

370 

L 

371 

M 

372 

N 

373 

D 

374 

P 

375 

Q 

376 

R 

377 

S 

378 

T 

379 

U 

380 

V 

381 

W 

382 

X 

383 

Y 

384 

Z 

385 

<M0DIFIED  VARIABLE>  **=  OHAR  ( <VARIABLE>  > 

386 

; BIT  ($  <NUMERIC  FORMULA>  $)  ( 

i 386 

<VARIABLE>  ) 

1 387 

> 

i 

1 BIT  ($  <NUMERIC  FORMULA>  , 

3b 


387 

387 

388 

389 

390 

391 

392 

392 

393 
393 

393 

394 
396 


<NUMERIC  F0RMULA>  $)  ( 
<VARIABLE>  ) 

I WANT  ( < VAR I ABLE > ) 

! NENT  ( < VAR I ABLE > ) 

{ POS  ( <IDENTIFIER>  ) 

: ODD  ( <VARIABLE>  ) 

I BYTE  ($  <NUMERIC  FOHMULA>  $)  ( 
<VARIABLE>  ) 

! BYTE  ($  <NUMERIC  FORMULA>  , 
<NUMERIC  FORMULA>  $)  ( 
<VARIABLE>  ) 

; ENTRY  ( <VARIABLE>  ) 

} ENT  ( <VARIABLE>  ) 


396  <8EGIN>  ii=  BEGIN 


397  <END>  its  END 


398  <BEGIN2>  ii=  BEGIN 


399  <END2>  i »=  END 


6.  The  Structured  t-xtensions  to  JOVIAL  J3 

Three  structured  extensions  to  JOVIAL  J3  have  been 
introduced  during  the  development  of  the  prototype  JSDD.  The 
JSDD  was  written  using  the  structured  extensions,  and  it  is 
capable  of  diagramming  JOVIAL  J3  programs  which  employ  them. 
Section  6.1  describes  the  structured  extensions  and  Section 
6.2  describes  their  translation  into  standard  JOVIAL  J3, 


6.1  STRUCTURED  EXTENSION  DEFINITIONS 

The  current  JOVIAL  J3  structured  extensions  are* 

1)  The  DO  rtHILE  LOOP 

2)  The  DO  UNTIL  LOOP 

3)  The  CASE  STATEMENT 

Their  syntactic  definitions  follow* 

<D0  WHILE  LOOP>  **=  do  while  [ <condition>  I <statement  list> 

[ end  do  <text>  ] 

<D0  UNTIL  LOOP>  **=  do  until  [ <condition>  ] <stateinent  list> 

I end  do  <text>  ] 

<CASE  STATEMENT>  **=  do  case  t <selector>  ] <case  list> 

I end  case  <text>  1 

<case  list>  **=  <case>  <statement  list> 

I <case> 

! <case  list>  <case>  <statement  list> 

! <case  list>  <case> 

<case>  **=  [ <number>  <text>  ] 

! [ else  <text>  I 

The  symbol  <text>  appearing  in  the  productions  presented 
above  is  an  optional  feature  which  allows  the  user  to  place 
quoted  or  unquoted  comments  inside  the  square  brackets. 

The  symbol  <condition>  can  be  any  boolean  formula  allowed  in 
a conditional  statement  in  standard  JOVIAL  J3. 

The  symbol  <selector>  can  be  any  JOVIAL  J3  variable, 
constant  or  function  call  which  has  an  integer  value. 

The  cases  in  the  CASE  STATEMENT'S  <case  list>  must  be 
numbered  sequentially  starting  with  zero.  One  "else  case" 
may  appear  anywhere  in  the  <case  list>. 


'fhe  structured  extensions  may  appear  wherever  a standard 
JOVIAL  J3  complex  statement  can  appear. 


A brief  description  of  the  semantics  associated  with  each  of 
the  structured  extensions  appears  below.  A better 
understanding  of  their  semantics  can  be  obtained  by 
examining  the  translations  presented  in  Section  6.2. 


The  DO  riHILt:  LOOP  causes  repeated  execution  of  its 
<statement  list>  while  its  <condition>  is  true.  Evaluation 
of  the  <condition>  is  performed  prior  to  the  execution  of 
the  <statement  list>.  If  the  value  of  the  <condition>  is 
false,  control  is  passed  to  the  statement  immediately 
following  the  [end  do]. 


The  DO  UNTIL  LOOP  causes  repeated  execution  of  its 
<statement  list>  while  the  value  of  its  <condition>  is 
false,  evaluation  of  the  <condition>  is  performed  after  each 
execution  of  the  <statenent  list>.  If  the  value  of  the 
<condition>  is  true,  then  control  is  passed  to  the  statement 
immediately  following  the  [end  do]. 


The  CASE  STATEMENT  evaluates  its  <selector>  and  transfers 
control  to  the  <case>  whose  <number>  corresponds  to  the 
value  of  the  <selector>.  If  no  corresponding  <case>  appears 
in  the  <case  iist>,  then  control  is  passed  to  the  "else 
case'-'  (if  one  is  present)  or  to  the  statement  iranediately 
following  the  [end  case]  (if  there  is  no  "else  case"). 


The  symbol  <statefflent  list>  refers  to  any  sequence  of 
standard  JOVIAL  J3  statements  and  structured  extensions. 


Transferring  control  to  a <case>  causes  execution  of  the 
<statement  list>  associated  with  the  <case>.  After  execution 
of  the  <statement  list>  has  been  completed,  control  is 
transferred  to  the  statement  immediately  following  the  [end 
case  ]. 


6.2 


Translating  Structured  Extensions 


Programs  incorporating  structured  extensions  are  translated 
into  standard  JOVIAL  J3  programs  by  the  JOVIAL  Extended 
Structures  Translator  (JEST  preprocessor).  JEST  is  a PL/I 
program  implemented  on  the  RADC  MULTICS  system. 


JHST  accepts  extended  JOVIAL  (standard  JOVIAL  plus 
structured  extensions)  programs  with  MULTICS  path-names 
having  the  suffix  '^.jovp^'.  The  sructured  extension 
keywords  (i.e.«  do,  while*  until*  case*  else  and  end)  must 
be  lower  case  in  the  input  program.  JEST's  output  is  a 
standard  JOVIAL  J3  translation  of  the  input  program.  The 
output  program  has  the  same  MULTICS  path-name  as  the  Input 
program  except  that  it  has  the  suffix  ".jov". 

JEST  is  invoked  by  typing  "jp  pgm'name''*  or  by  invoking 
the  jovial  EXEC_COM  (See  Appendix  A). 

JEST  translates  only  those  blocks  of  code  which  it 
recognizes  as  structured  extensions.  Any  code  which  is  not 
recognized  as  being  a structured  extension  is  passed  to  the 
output  file  unchanged. 

Structured  extensions  and  their  translations  are  presented 
be  low. 

The  DO  rtHILE  LOOP* 

do  while  [condition] 

code  block  a 

[end  do] 
code  block  b 

translates  into* 

while'label.  if  condition  $ 
begin 

code  block  a 
goto  while' label  $ 

end 

code  block  b 


The  DO  UNTIL  LOOP* 

do  until  [condition] 

code  block  a 

[end  do] 
code  block  b 

is  translated  into* 
until'label . 

code  block  a 

if  not  condition  $ goto  until'label  $ 
code  block  b 
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JEST  emits  two  types  of  translations  of  CASE  STATEMENTS.  Ihe 
first  translation  is  used  on  CASE  STATEMENTS  whose  <case 
llst>s  contain  100  <case>s  or  less,  l^he  second  translation 
is  used  for  CASE  STATEMENTS  having  more  than  100  <case>s. 

Consider  the  pseudo  statement < 

do  case  [selector! 

[0]  code  block  0 

[ 1 ] code  block  I 
[2!  code  block  2 


[n!  code  block  n+l 

[end  case! 
code  block  n+2 

If  n is  less  than  100,  the  JEST  translation  of  the  CASE 
STAEMENT  iss 

goto  process-'label  $ 
case'label-'O. 

code  block  0 
goto  escape'label  $ 
case'label' 1 . 

code  block  I 
goto  escape'label  $ 


• 

case'label^n. 

code  block  n 
goto  escape^label  $ 
else'label. 

code  block  n+l 
goto  escape'label  $ 

switch  case^control  = ( case' label^O, . . . ,case'label'n)  $ 
proce ss' label. 

goto  case'control  ($selector$)  $ 
goto  else'label  $ 
escape'label. 

code  block  n+2 

Unfortunately,  the  JOVIAL  J3  compiler  imposes  a limit  on  the 
number  of  labels  that  may  appear  in  a single  SWITCH 
DECLARATION.  The  limit  seems  to  be  around  100.  For  this 
reason,  a more  complicated  translation  is  necessary  for  CASE 
STATEMENTS  having  more  than  100  cases.  If,  in  the  above 
example  the  value  200  is  assigned  to  n,  the  translation  of 
the  pseudo  statement  takes  the  following  formt 


goto  process'label  $ 
case' label'O. 


code  block  0 
goto  escape'label  $ 
case' labe 1' I . 

code  block  I 
goto  escape'label  S 


case'label' I 99. 

code  block  199  S 
goto  escape'label  $ 
else' label. 

code  block  200 
goto  escape'label  $ 

swi tch  block' I = ( case'label'O, . . . , case'label'99)  $ 

switch  block'2  = (case'label ' I 00, ..., case'label' 1 99)  $ 

switch  control'switch  = (block' I 'label, block'2'l6bei ) S 

item  switch'block  i 36  s $ 

item  switch'displacement  i 36  s S 

proce  ss'label . 

re.Tiquo(selector,  I (X)=swl tch'block , switch'displacement ) $ 
goto  control'switch  ( Sswitch'blockS ) $ 
goto  else'label  S 
block' I 'label . 

goto  block'l  ($switch'displacement$ ) S 
block'2'label . 

goto  block'2  ( Sswitch'displacei!ient$  ) $ 
goto  else'label  S 
escape'label . 
code  block  201 


JEST  generates  labels  of  the  form  "zzzn"  where  n is  a 
non-negative  integer.  The  programmer  using  JEST  should  take 
care  to  avoid  any  labelling  conflicts  with  the 
JhST-generated  labels. 

Throughout  the  JSUD  development,  the  JEST  preprocessor  has 
been  heavily  used  and  has  proven  to  be  completely  reliable. 
This  reliability  has  been  such  that  JSDO  debugging 
activities  have  been  focussed  on  the  extended  JOVIAL  code 
rather  than  on  the  somewhat  obtuse  JEST-generated  code. 


I 


7,  Conclusions  and  Recommendations 


The  principal  utility  of  Structured  Design  Diagrams  (SDDs) 
and  Invocation  Diagra.ns  is  that  they  provide  readable* 
graphic  portrayals  of  the  nested  logical  sequences  that 
define  the  structure  of  a computer  program  or  of  a system 
design  v#ri  tten  in  some  higher  order  design  language.  The 
prototype  JOVIAL  Structured  Design  Diagraminer  (JSDD)  was 
implemented  to  process,  as  input,  digital  computer  programs 
written  in  JOVIAL  J3  (with  or  without  structured  extensions) 
and  to  produce,  as  output,  SDDs  and  Invocation  Diagrams. 
The  JOVIAL  J3  grammar  processed  by  the  JSDD  was  extracted 
from  the  definition  in  reference  4.  Due  to  certain 
ambiguities  in  the  JOVIAL  J3  language  (see  Section  b),  it 
was  necessary  to  relax  some  constraints  on  the  JSDD  grammar 
so  that  the  JSDD  parses  JOVIAL  J3  programs  as  a subset  of  a 
wider  grammar.  The  structured  extensions  are  based  upon  the 
structured  extensions  to  JOVIAL  J3  as  described  in  reference 
b. 


SDDs  produced  from  source  code  that  uses  structured 
constructs  convey  better  information  about  program  structure 
than  those  produced  from  code  that  does  not  obey  the 
precepts  of  Structured  Programming,  therefore,  the  use  of 
the  structured  extensions  supported  by  the  JSDD  is 
encouraged.  Programs  that  make  use  of  the  structured 
extensions  need  a preprocessor  to  convert  them  into  source 
code  that  is  acceptable  to  the  JOVIAL  J3  compilers.  Such  a 
preprocessor  has  been  supplied  as  a deliverable  with  the 
JSDD,  See  Appendix  A for  a complete  list  of  deliverables. 
That  preprocessor  was  used  to  convert  the  source  code  of  the 
JSDD,  which  was  written  with  structured  extensions,  into 
compilable  source  code.  Because  of  the  structured 
extensions,  the  JSDD  is  a structured  program;  therefore,  it 
was  possible  to  use  the  JSDD  to  provide  excellent  quality 
design  diagrams  of  its  own  source  code.  The  SDDs  and 
Invocation  Diagrams  of  the  JSDD  programs  are  incorporated  in 
the  JSDD  Program  Description,  a companion  volume  to  this 
report. 


To  get  full  utility  from  the  Structured  Design  Diagraminer, 
one  wo(Jid  have  to  integrate  the  JSDD  programs  into  a 
comprehensive  documentation  system.  The  JSDD  would  require 
additional  design  features  to  achieve  its  full  potential.  A 
list  of  desirable  additional  features  follows* 


1.  Qptional  facilities  for  page  formatting  and  pen 
plotting  should  be  implemented. 

2.  Concordance  listings  and  data  summaries  should  be 
optionally  available  to  the  JSDD  user. 

3.  Statements  on  the  SDDs  should  be  annotated 
optionally  with  sequence  numbers  that  agree  with  the 
JOVIAL  compiler  listing. 

4.  The  JSDD  Symbol  Table  capability  should  be  enhanced 
and  its  content  appropriately  written  to  a data  base. 
This  data  base  should  be  accessible  to  Interactive 
software  tools  that  can  aid  the  user  in  understanding 
the  interaction  of  variables  in  the  computer  program. 


The  JSDD's  Invocation  Diagrammer  is  an  example  of  a software 
tool  which  processes  a subset  of  the  JSDD  symbol  table 
information  described  in  item  4 above. 


From  the  implementor's  point  of  view  the  JOVIAL  J3  language 
was  not  a good  choice  of  a programming  language  in  which  to 
implement  the  JSDD.  For  instance,  the  JOVIAL  J3  compiler 
supplied  for  use  on  this  contract  was  incapable  of 
optimizing  the  JSDD  programs.  Even  if  this  were  not  the 
case,  the  JSKD  would  still  run  more  slowly  than  necessary, 
because  much  computer  time  is  consumed  performing  operations 
for  which  the  JOVIAL  J3  compiler  is  not  very  efficient.  For 
example,  a major  shortcoming  of  the  compiler  is  that  it  does 
not  support  random  access  output  operations  on  disk  files. 
This  induces  the  JSDD  to  consume  great  amounts  of  computer 
time  doing  double  buffered  I/O,  and  requires  the  inclusion 
of  additional  software  modules  in  the  JSDD  computer 
programs. 


Two  additional  aspects  of  the  JOVIAL  J3  language  render  it 
less  than  desirable  for  the  JSDD  application  or  for 
*«:pleinenting  compiler-like  tools  in  general.  First,  the 
static  nature  of  JOVIAL's  data  handling  makes  it  difficult 
to  do  dynamic  memory  . management.  Second,  JOVIAL  does  not 
contain  string  handling  constructs  that  are  naturally  suited 
to  compiler-like  programming.  The  outstanding  difficulty 
with  the  JOVIAL  character  string  manipulation  capability  is 
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that  the  current  string  length  and  the  "declared"  maximum 
string  length  for  a string  variable  are  not  available  at 
execution  time.  In  order  to  circumvent  the  string  handling 
dlff IcultleSf  the  character  string  handling  package  Is 
Incorporated  into  each  JSDD  program.  This  package  offers 
string  operations  such  as  substring  and  concatenation. 

Despite  the  difficulties  attendant  to  the  implementation* 
the  JSDD  produces  Structured  Design  Diagrams  of  high 
quality.  The  JOVIAL  programmer  should  find  these  diagrams 
to  be  of  great  assistance  during  program  design  and 
implementation  as  well  as  being  useful  for  documentation 
purposes.  The  Invocation  Dlagrammer  produces  an  output  that 
is  extremely  useful  and  probably  should  long  have  been  a 
standard  feature  of  commercial  compilers.  The  prototype 
JSDD  has  been  designed  such  that  it  can  also  serve  as  the 
nucleus  of  a comprehensive  automated  documentation  system 
for  JOVIAL  programs,  should  the  construction  of  such  a 
system  be  desired  at  a later  time. 
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Appendix  A.  The  Deliverables 


In  accordance  with  contract  number  F30602-76-C-0409  with  the 
Rome  Air  Devleopment  Center  at  Griffis  Air  Force  Base*  the 
Charles  Stark  Draper  Laboratory  has  delivered  the  following 
three  Items. 

1)  CDRL  Item  A003,  The  JOVIAL  Structured  Design 

Diagrammer  Final  Report 

2)  CDRL  Item  A004,  The  JOVIAL  Structured  Design 

Diagrammer  Program  Description  and  The  JOVIAL 
Structured  Design  Diagrammer  User^s  Manual 

3)  CDRL  Item  B-6-3308,  Annex  I to  SOW  Item  I,  Digital 
Computer  Software 

The  listings  of  the  source  programs  have  been  transmitted  to 
RADC  via  the  RADC  MULTI CS  system.  The  digital  computer 
software  has  been  delivered  via  a RADC  MULTICS  directory 
hierarchy  'accessible  to  RADC  contracts  personnel.  Each 
subdirectory  within  the  hierarchy  contains  an  explanatory 
segment  named  info.  These  explanatory  segments  are  presented 
below. 

The  deliverables  directory  contains  all  software  tools 
developed  by  the  Charles  Stark  Draper  Laboratory,  Inc., 
Cambridge,  Ma,  under  contract  F30602-76-C0408  with  the  Rome 
Air  Development  Center  at  Griffis  Air  Force  Base. 

The  Deliverables  directory  contains  the  five  subdirectories 
listed  belowt 

1)  dddg  Contains  all  Design  Diagrammer  Data  Base 

Generator  software, 

2)  ddg  Contains  all  Design  Diagrammer  software. 

3)  irivoc  Contains  all  Invocation  Diagrammer  software, 

4)  jest  Contains  all  preprocessor  software. 

5)  util  Contains  support  software. 


The  directory  deliverables>ddg  contains  all  Design  Diagram 
Generator  (DDG)  software.  It  contains  the  four 
subdirectories  listed  belowt 

1)  source  Contains  source  code  for  the  DDG. 

2)  compools  Contains  source  versions  of  the  DDG  compools. 

3)  obj  Contains  object  code  for  compiling  and  running 

i 


the  DDU. 

4)  control  Contains  the  control  segments  for  running  and 
compiling  the  DUG. 


The  directory  deliverables>ddg>source  contains  two  source 
versions  of  the  DDG*  ddg.jovp  and  ddg.jov. 

The  segment  ddg.jovp  is  the  primary  source  version.  It  is 
written  in  extended  JOVIAL  (i.e.,.  JOVIAL  J3  plus  structured 
extensions).  All  development  work  was  performed  on  ddg.jovp. 


The  segment  ddg.jov  is  the  preprocessed  version  of  ddg.jovp. 
It  consists  of  standard  JOVIAL  J3  code.  The  segment  ddg.jov 
was  obtained  by  executing  the  JEST  preprocessor  with  the 
input  segment  ddg.jovp. 


The  directory  deliverables>ddg>compools  contains  the  source 
versions  of  the  compools  used  by  the  DDG.  They  are* 

1)  spool. cmp  Contains  the  string  package  global 

declarations . 

2)  debug. cmp  Contains  the  DDG  debug  switches. 

3)  opt. cmp  Contains  the  DDG  options. 


The  directory  dell verables>ddg>ob j contains  object  segments 
and  crip_out  segments  (used  for  compiling  DDG  elements). 
They  are* 

))  spool. obj  Global  string  package  declarations. 

2)  spool .cmp_out 

3)  debug. obj  DDG  debugging  switches. 

4)  debug. cnip_out 

5)  opt. obj  DDG  options. 

6)  opt.cmp_out 

7)  ddg.obj  The  DDG. 


The  directory  deliverables>ddg>control  contains  the  control 
segments  needed  to  invoke  the  G(XIS  simulator  for  a 
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compilation  or  execution.  The  segments  aret 


1)  ddg.Jin  Compiles  the  DDG, 

2)  ddg.rin  Executes  the  DUG. 

3)  spool. cin  Compiles  spool. cmp. 

4)  debug. cin  Compiles  debug. cmp. 

5)  opt. cin  Compiles  opt. cmp. 


The  directory  dellverables>dddg  contains  all  Design 
Dlagrammer  Data  Base  Generator  (DDDG)  software.  It  contains 
the  four  subdirectories  listed  below* 

1 ) source  Contains  source  code  for  the  DDDG. 

2)  compools  Contains  source  versions  of  the  DDDG  compools. 

3)  obj  Contains  object  code  fcr  compiling  and  running 

the  DDG. 

4)  control  Contains  the  control  segments  for  running  and 

compiling  the  DDG. 


The  directory  deliverables>dddg>source  contains  two  source 
! versions  of  the  DDDG*  dddg.  jovp  and  dddg.jov.  Two  source 

versions  of  the  external  procedure  synth,  synth. jovp  and 
• synth. JoVt  are  also  in  the  directory. 

I The  segment  dddg. Jovp  is  the  primary  source  version.  It  is 

I written  in  extended  JOVIAL  (i.e.,  JOVIAL  J3  plus  structured 

1 extensions).  All  developmental  work  was  performed  on 

dddg. jovp. 

^ The  segment  dddg.jov  is  the  preprocessed  version  of 

dddg. Jovp.  It  consists  of  standard  JOVIAL  J3  code.  The 
I segment  dddg.jov  was  obtained  by  executing  the  JEST 

I preprocessor  with  the  input  segment  dddg. Jovp. 

i 

I 

The  directory  deliverables>dddg>compools  contains  the  source 
versions  of  the  compools  used  by  the  dddg.  They  are* 

1)  spool. cmp  Contains  the  string  package  global 

declarations. 

2)  data. cmp  Contains  the  dddg  gloabal  declarations. 

3)  ntables.cmp  (Contains  the  parsing  tables  used  by  the 

dddg . 
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The  directory  deiiverables>dddg>obj  contains  object  segments 
and  cmp_out  segments  used  for  compiling  the  dddg. 

They  are* 


1)  data.obj  Global  dddg  declarations. 

2)  data.cmp_out 

3)  ntables.obj  Parsing  tables. 

4)  ntables.cmp_out 

5)  spool. obj  String  package  global  declarations. 

6)  spool .cmp_out 

7)  synth.obj  The  dddg's  external  procedure. 

8)  dddg.obj  The  dddg. 


The  directory  dellverables>dddg>control  contains  the  control 
card  segments  needed  to  Invoke  the  GUOS  simulator  for  a 
JOVIAL  compilation  or  execution.  The  segments  are* 

1)  dddg. Jin  Compiles  the  dddg. 

2)  dddg.rln  Executes  the  dddg. 

3)  synth.Jln  Compiles  synth.Jov. 

4)  data.cin  Compiles  data.cmp. 

5)  ntables.cin  Compiles  ntables. crnp. 

6)  spool. cln  Compiles  spool. crnp. 


The  directory  dellverables>invoc  contains  all  Invocation 
Dlagrammer  software.  It  contains  the  four  subdirectories 
listed  below* 

1)  source  Contains  source  code  for  the  Invocation 

Dlagrammer. 

2)  compools  Contains  source  versions  of  the  Invocation 

Diagrammer  compools. 

3)  obJ  Contains  object  code  for  compiling  and  running 

the  Invocation  Diagrammer. 

4)  control  Contains  the  control  segments  for  running  and 

compiling  the  Invocation  Diagrammer. 


i 
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The  directory  deliverables>invoc>souree  contains  two  source 
versions  of  the  Invocation  Diagrammer*  Invoc.jovp  and 
invoc.  .lov. 

The  segment  invoc.jovp  is  the  primary  source  version.  It  is 
written  in  extended  JOVIAL  (i.e.,  JOVIAL  J3  plus  structured 
extensions).  All  development  work  was  performed  on 
invoc.jovp. 


The  segment  invoc. Jov  is  the  preprocessed  version  of 
invoc.jovp.  It  consists  of  standard  JOVIAL  J3  code.  The 
segment  invoc.  Jov  was  obtained  by  exectiting  the  JEST 
preprocessor  with  the  input  segment  invoc.jovp. 


The  directory  deliverables>invoc>compools  contains  the 
source  versions  of  the  compools  needed  to  run  the  Invocation 
Diagrammer. 

They  are* 


1)  opt.cmp  The  options  compool. 

2)  spool. cmp  The  string  package  compool. 


The  directory  deliverables>invoc>ob j contains  the  object 
segments  and  cmp_out  segments  (used  for  compiling  the 
Invocation  Diagrammer)  relating  to  the  Invocation 
Diagrammer. 


They 

' are* 

1 ) 

invoc.ob J 

The 

2) 

spool . ob  J 

The 

3) 

spool . cmp_out 

4) 

opt.obj 

The 

5) 

opt. cmp_out 

i 

Invocation  Diagrammer.  | 

string  package  declarations.  1 


Invocation  Diagrammer  options. 


< 

\ 


The  directory  dellverables>lnvoc>control  contains  the  GCQS 
control  card  segments  used  for  running  and  compiling  the 
Invocation  Diagrammer.  They  are* 


( 

i 


i 
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1)  invoc.jin 

2)  invoc.rin 

3)  spool. cin 

4)  opt. cin 


Compi les 
Runs  the 
Compiles 
Compi les 


the  Invocation  Diagrammer. 
Invocation  Diagrammer. 
spool . cmp. 
opt. cmp. 


The  directory  deliverables> Jest  contains  the  source  and 
object  versions  of  the  JOVIAL  Extended  Structures  Translator 
(JEST).  JEST  is  a preprocessor  which  translates  programs 
written  in  extended  JOVIAL  (i.e.i  JOVIAL  J3  plus  structured 
extensions)  into  standard  JOVIAL  J3  programs.  JEST  is  a PL/I 
program  developed  to  work  in  a MULTICS  environment. 


The  directory  dellverables>util  contains  the  MULTICS  system 
support  software  developed  for  the  JSDD  effort.  It  has  two 
subdirectories,  exec_coms  and  code.  The  exec_com 
subdirectory  contains  the  MULTICS  exec_coms  developed  by 
Victor  Voydock  which  generate  GCOS  control  cards.  The 
subdirectory  code  contains  utility  software  used  throughout 
the  project. 


The  directory  deliverables>uti l>exec_coms  contains  the 
MULTICS  exec_coms  which  were  developed  to  automatically 
generate  GCXIS  Job  control  card  decks.  The  following  is  a 
list  of  the  exec_coms  accompanied  by  a brief  description. 


gcos_setup.ec  **** 


A number  of  exec_com^s  have  been  created  to  make  it  easier 
to  compile  programs  using  translators  which  run  under  the 
GCOS  environment  simulator  and  to  execute  the  resulting  GCOS 
object  programs. 

This  is  a description  of  what  must  be  done  to  set  up  a ' 
process  environment  in  which  these  exec_com's  can  be  used. 
The  actual  use  of  the  Individual  exec_com''s  is  described 


below 


r 

\ 


r 
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Once  the  following  instructions  are  followed,  the  exec_coms 
may  be  used  directly  as  commands  as  described  below. 


Table  of  Contentsi 

The  following  are  available* 


Jovial 

compool 

gf  ort 
gmap 
run 
prr 


compile  a Jocit  JOVIAL  program 

compile  a compool  to  be  used  by  other  Jocit  JOVIAL 
programs 

compile  a GCOS  FORTRAN  program 

assemble  a GMAR  (GCOS  assembly  language)  program 
load  and  execute  one  or  more  GCOS  object  programs 
print  edited  version  of  program  run  output 


I nstructions  * 

To  use  the  above  exec_coms  directly  as  commands  do  the 
following* 


I)  Using  the  "link"  cotnniand,  put  the  following  link  in 
your  "search"  directory*  (this  link  may  already  exist;  if 
so,  the  link  command  will  ask  you  if  you  wish  to  delete 
the  old  link;  you  should  answer  yes) 
>udd>f c>vlv>Library>on 


2)  In  the  abbrev  command  lines  listed  below,  you  should 
replace  ZZZ  by  your  initials  (in  lower  case).  The  rest  of 
the  line  should  be  typed  literally  as  shown  below.  For 
example, 

[user  name] 

means  type  a left  bracket  followed  by  the  word  "user", 
followed  by  the  word  "name",  followed  by  a right  bracket. 


****  Install, ec 


The  install  exec_com  "installs"  new  versions  of  the  Jovial, 
compool,  run,  gfort,  and  gmap  exec_coms  in  the  directory 
>udd>f c>vlv>l ib. 


NOTE!  THIS 
DIRECTORY  ISi 


EXEC_COM  ASSUMES  THAT  THE  USER'S  WORKING 


>udd>f lowchart>Voydock>Library 


Syntax* 

cwd  >udd>f c>vlv>lib  ec  install  name 


Argument » 

name  is  the  name  of  the  segment  (minus  the  '’ec"  suffix)  to 
be  installed. 


Notes  * 

The  installation  process  is  as  follows* 

1)  The  segment  ''name.ec”  in  >udd>Elowchart>Voydock>Library 
(hereinafter  called  "the  library")  is  renamed  to  name.X.ec 
where  X is  the  date  and  time  the  installation  began. 

2)  All  other  names  on  the  old  name.ec  are  removed 

3)  The  segment 

>udd>Flowchart>Voydock>gcos„exec_com_dev>name. ec  is  copied 
into  the  library. 

4)  The  names  of  all  exec_coms  invoked  with  name.ec  are 
converted  from  relative  to  absolute  pathnames.  This  is 
necessary  to  avoid  forcing  the  user  to  know  the  names  of 
all  the  exec_coms  invoked  in  name.ec  and  having  to  place 
links  to  all  of  them  in  any  directory  which  will  be  his 
working  directory  when  name.ec  is  invoked. 


*★**  jovial.ee  •*•*** 


The  Jovial  command  allows  the  user  to  easily  ir.voke  the 
Jocit  JOVIAL  compiler  which  runs  under  the  Multics  GCOS 
Environment  Simulator  to  translate  a segment  containing  a 


JOVIAL  source  program  into  a GCOS  format  object  segment 
which  can  be  executed  using  the  run  command.  A listing 
segment  is  optionally  produced. 

The  following  output  line  is  always  printed  out  by  the  Jocit 
compiler.  There  is  no  way  to  suppress  it,  and  is  not 
indicative  of  a major  problemi 

gcos_mm_info_*  mme  geinfo  will  not  return  a copy  of  the  SSA. 


Syntax* 

jovial  path  -jocit_options- 


Arguments* 

path  is  the  pathname  of  a JOVIAL  source  segment  that  is  to 
be  translated  by  the  Jocit  JOVIAL  compiler.  The  actual 
entry  name  of  the  source  segment  must  have  the  suffix  "jov". 
If  path  does  not  have  the  suffix  “jov”  then  one  is  assumed. 
That  is,  the  following  two  command  lines  are  identical* 

jovial  my_program. jov 
jovial  my_program 

joci t_options  are  options  accepted  by  the  Jocit  compiler. 
See  the  Jocit  Compiler  User-'s  Manual  for  a list  of 
acceptable  options.  If  multiple  options  are  specified,  they 
must  be  separated  by  commas.  No  embedded  blanks  are 
allowed. 


Output  Segments* 

The  following  output  segments  are  produced  in  a subdirectory 
of  the  user's  working  directory  named  jovwrk  (which  is 
created  if  it  doesn't  exist)  during  the  compilation  of  the 
segment  myprog.jov* 

myprog.ob j 

GCOS  format  object  program  which  is  the  translation  of 
myprog.jov.  The  program  may  be  executed  by  the  run 
command. 

myprog.list 


Listing  segment  produced  by  the  compiler  in  response  to 
user  specified  options. 


myprog. compile. list 

Output  of  the  GCOS  environment  simulator, 
usually  of  no  interest  to  the  user. 


This  is 


myprog. jin 

Card  images  of  GCOS  control  cards  produced  by  the 
Jovial  command  to  cause  the  GCOS  enivronment  simulator 
to  perform  the  translation.  Usually  of  no  interest  to 
the  user. 


Notes* 

1)  If  a "jin”  segment  already  exists  when  the  jovial 
command  is  invoked,  the  user  is  asked  if  he  wants  to  use 
it.  I f he  answers  "yes"  then  the  old  segment  is  used 
without  change.  If  he  answers  "no"  then  the  old  segment 
is  deleted  and  a new  "jin"  segment  is  generated. 

2)  If  a "jin"  segment  is  being  generated,  the  command  asks 
the  user  for  the  names  of  the  compool  segments  to  be  used 
during  this  compilation.  The  names  should  be  all  typed  on 
the  same  line  separated  by  at  least  one  space.  The  names 
should  be  typed  without  the  "ciiip_out"  suffix.  The 
compools  must  previously  have  been  compiled  using  the 
compool  command.  If  no  compools  are  to  be  used,  a blank 
line  should  be  typed. 

3)  The  jovial  command  automatically  compiles  all  programs 
with  the  compool 
>udd>b lowchart>Voydock>Library>uti 1 it ies . cmp_out  whi ch 
contains  various  useful  external  procedure  declarations. 

4)  The  jovial  command  automatically  adds  the  following 
options  to  the  list  of  user  specified  options* 


xref 

map 

ncomdk 

name/xxxxxx/ 

where  xxxxxx  is  the  first  six  characters  of  the  name  of 
the  program  being  compiled.  The  ncomdk  option  suppresses 


the  production  of  a compressed  source  card  image  optput 
file  which  is  of  no  interest  to  the  user.  The  Jocit 
manual  claims  ncoiiidk  is  the  default  but  this  is  not  the 
case. 

b)  Since  the  " jin'*  and  "coinpi  le.  list”  segments  are  not  of 
general  interest  and  tend  to  clutter  up  one's  directory, 
the  user  may  wish  to  use  abbrev  or  exec_com  to 
automatically  delete  these  segiiients  after  translation  is 
completed.  This  feature  may  later  be  added  as  a control 
argument  to  the  jovial  command. 


hxai'iple* 

The  following  command  line  will  translate  the  source 
program  >any_dir>some_prog. jov  using  the  xref,  map,  and 
Istou  compiler  options  and  store  the  output  segments  in 
the  jjser's  current  working  directoryi 


jovial  >any_di r>some_prog  Istou 


★***  cornpool.ee  **★* 


The  compool  command  allows  the  user  to  easily  invoke  the 
Jocit  JnviAL  compiler  which  runs  under  the  Multics  GCOS 
Environment  Simulator  to  translate  a segment  containing  the 
source  code  of  a JOVIAL  cornoool. 


Syntax* 

compool  path  - joci t_options- 


Arguments* 

path  is  the  pathname  of  a JOVIAL  compool  source  segment  to 
be  translated  by  the  Jocit  JOVIAL  compiler.  The  actual 
entry  name  of  the  source  segment  must  have  the  suffix  "cmp”. 
If  path  does  not  have  the  suffix  "cmp”  then  one  Is  assumed. 
That  is,  the  following  two  command  lines  are  identical* 


compool  my_program.ctr'p 


cotnpool  tny_program 


Joel t_options  are  options  accepted  by  the  Jocit  compiler. 
See  the  Jocit  Compiler  User's  Manual  for  a list  of 
acceptable  options.  If  multiple  opti.ons  are  specified,  they 
must  be  separated  by  commas.  No  embedded  blanks  are 
allowed. 


Output  Segments! 

The  following  output  segments  are  produced  in  a subdirectory 
of  the  working  directory  called  Jovwrk  during  the 
compilation  of  the  segment  myprog.cmp* 

myprog.cmp_out 

Contains  the  translated  form  of  the  procedure  and  data 
declarations  of  the  source  compool  which  do  not 
actually  generate  any  storage.  That  is,  procedure 
declarations  and  non  compool  common  data  declarations. 

myprog.obj 

Contains  storage  for  compool  common  data  declared  in 
the  source  compool.  In  theory,  if  there  are  no  compool 
common  data,  this  segment  should  not  be  produced. 
However,  the  compiler  seems  to  always  produce  this 
segment.  In  the  case  when  there  are  no  compool  common 
data,  it  seems  from  empirical  evidence  to  be  safe  to 
ignore  the  "obj”  segment. 

myprog. 1 ist 

Listing  segment  produced  by  the  compiler  in  response  to 
user  specified  options. 

myprog. compile. list 

Output  of  the  GCOS  environment  simulator.  Tliis  is 
usually  of  no  interest  to  the  user. 

myprog. cl n 

Card  images  of  GDIS  control  cards  produced  by  the 
Jovial  command  to  cause  the  GCOS  enivronment  simulator 
to  perform  the  translation.  Usually  of  no  interest  to 
the  user. 
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1)  If  a "cln"  segment  already  exists  when  the  compool 
command  is  invokedi  the  user  is  asked  if  he  wants  to  use 
it.  If  he  answers  "yes'*  then  the  old  segment  is  used 
without  change.  I f he  answers  "no"  then  the  old  segment 
is  deleted  and  a new  "cin"  segment  is  generated. 

2)  The  compool  command  automatically  adds  the  following 
options  to  the  list  of  user  specified  options* 

ncomdk 

nanie/xxxxxx/ 

where  xxxxxx  is  the  first  six  characters  of  the  name  of 
the  compool  being  translated.  The  ncomdk  option 
suppresses  the  production  of  a compressed  source  card 
image  optput  file  which  is  of  no  interest  to  the  user. 
The  Joclt  manual  claims  ncomdk  is  the  default  but  this  is 
not  the  case. 

3)  Since  the  "cin"  and  "compile. list"  segments  are  not  of 
general  interest  and  tend  to  clutter  up  one's  directory, 
the  user  may  wish  to  use  abbrev  or  exec_com  to 
automatically  delete  these  segments  after  translation  is 
completed.  This  feature  may  later  be  added  as  a control 
argument  to  the  compool  command. 


txample* 

The  following  command  line  will  translate  the  source 
program  >any_dir>some_prog.cmp  using  the  xref,  map,  and 
Istou  compiler  options  and  store  the  output  segments  in 
the  user's  current  working  directory* 

compool  >any_dir>some_prog  xref , map, Istou 


ieiclrk  run.CC 


Tlie  run  command  allows  the  user  to  execute  one  or  more  GCDS 
format  object  segments  using  the  GCOS  environment  simulator. 
A current  implementation  restriction  allows  only  object 
segments  produced  by  the  JOVIAL  compiler  to  be  run. 


Syntax* 

run  pathl  pathQ 


Arguments* 

pathl  ...  pathn  are  the  pathnames  of  the  object  segments  to 
be  run.  The  actual  entry  names  of  the  object  segments  must 
have  the  suffix  "obj".  BUT  the  pathnames  given  in  the 
coitifnand  line  must  not  specify  the  ''obj"  suffix.  That  is, 
the  cominand  line* 

run  first_prog  my_prog 

is  legal.  Whereas  the  command  line* 

run  first_prog.ob j my_prog.obj 

is  not. 

Output  Segments* 

The  following  output  segments  are  produced  in  a subdirectory 
(Jovwrk)  of  the  user's  working  directory  during  the 
execution  of  the  run  command* 

firs  t_prog . run .list 

Where  "f  irst_prog''  is  the  first  object  segment 
specified  in  the  command  line.  This  segment  contains 
two  types  of  output.  First  it  contains  output  produced 
by  the  GCOS  simulator  during  the  execution.  This  is 
usually  of  little  interest  to  the  user.  Then  it 
contains  all  program  output  directed  to  logical  unit 
number  06  and  all  output  produced  by  monitor 

statements. 

The  prr  command  allows  the  user  to  print  the  contents 
of  this  segment  ignoring  the  GCOS  simulator  output. 

There  is  no  way  to  divert  output  directed  to  logical 

unit  number  06  to  the  terminal.  To  print  output  on  the 
terminal  use  the  trmout  and  tout  procedures. 

'fhere  currently  is  no  way  to  divert  monitor  output  to 
the  terminal.  This  is  a problem  in  the  Jocit  runtime 
library.  It  is  being  looked  at  by  the  compiler 

implementors. 
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f ir3t_proy,rin 

This  segment  contains  card  images  of  GCOS  control  cards 
produced  by  the  run  command  to  cause  the  GCOS 
enviroiiient  simulator  to  execute  the  programs.  Usually 
it  is  of  no  interest  to  the  user. 


Notes  * 

1)  If  a 'Tin*'  segment  already  exists  when  the  run  cormnand 
is  invoked,  the  user  is  asked  if  he  wants  to  use  it.  If 
he  answers  “yes''  then  the  old  segment  is  used  without 
change.  If  he  answers  “no"  then  the  old  segment  is 
deleted  and  a new  “rin"  segment  is  generated. 

2)  If  a “jin''  segment  is  being  generated,  the  command  asks 
the  user  for  the  names  of  the  files  which  will  be 
referenced  during  the  execution  of  the  object  programs. 
The  names  should  all  be  typed  on  the  same  line  separated 
by  at  least  one  space.  Outpiit  files  need  not  exist  when 
the  run  command  is  invoked  i they  are  automatically  created 
when  needed.  The  files  are  assigned  logical  unit  numbers 
starting  with  11  (that  is,  the  first  file  specified  is 
assigned  11,  the  second  12,  etc.).  The  file  declarations 
in  the  object  programs  must,  of  course,  assign  logical 
unit  numbers  accordingly. 

3)  Tha  logical  unit  number  08  is  reserved  for  use  by  the 
trifiin  procedure,  the  unit  09  is  reserved  for  use  by  the 
trmout  procedure,  unit  10  is  reserved  for  possible  special 
use.  None  of  these  unit  numbers  should  be  used  by  user 
programs . 

A)  Tiae  run  command  automatically  loads  the  tnnin,  trmout, 
tout  and  frstnb  programs  for  every  execution. 

■k-kick  prr.ec  **** 


The  prr  coiiKnand  prints  the  results  of  a run  stored  in  a 
“run. list"  segment  starting  with  the  line  containing  the 
string  "liXhiCUTiaN  PNQGHAM  ENTERED  AT"  That  is,  it  ignores 
all  of  the  output  of  the  simulator  (load  map,  etc.)  which 
is  usually  of  no  interest  to  the  user. 


oj 


Syntax I 
prr  path 


I Argument  I 

[ path  is  the  pathname  of  the  segment  containing  the  output  to 

be  printed.  The  actual  name  of  the  segment  must  have  the 
suffix  “run. list".  However  this  suffix  must  not  be 
specified  in  path.  That  is, 

prr  my_prog 

is  legal!  whereas 

prr  my_prog. run. list 

is  not. 

**★*  on . e c **** 


Function*  on  is  a condition-handling  program  for  commands. 


Syntax*  on  condname  handler_com_line  options 
subJect_com_line 


Arguments*  “sub  ject_com_line''  will  be  executed.  if 
condition  “condname''  is  raised,  then  the  handler  for  it  will 
call  cu_$cp  to  execute  the  line  ''handler_com_line“. 


Control  arguments*  -brief  (-bf)  to  suppress  the  comment 
when  condition  is  raised  -retry  to  return  to  point  of 
fault  after  handler  -long  (-lg>  to  print  machine  conditions 
when  condition  raised  -cl  to  call  cu_Scl  after  handler 
(command  level,  preserves  machine  conditions) 


Notes* 

Normal  action  after  handler  is  to  do  a non-local  goto  and 
contintje  to  the  next  command  after  “on". 


ol 
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"subject_com_line"  begins  with  first  non-option  and  need 
not  be  enclosed  in  quotes  ( ''handler_com_l Ine"  must  be 
though).  If  “condname"  is  then  an  any_other  handler 
is  set  up  In  this  case«  ••alrra",  "cput”,  “quit",  and 
“program_lnterrupt“  will  not  activate  the  handler. 


Examples*  on  * ”ec  error"  -Ig  v2pl I foobar  on  quit  ts  on 
* ts  myprogram$myprogram  I on  command_error  db  -rt  -bf 
foobar  on  accessviolatlon  *sa  &l  rewa"  -rt  print 


The  directory  dellverables>util >code  contains  the  JSDD 
software  support  code.  The  segments  contained  in  the 
directory  are  listed  below  accompanied  by  brief  descriptions 
of  their  purpose  and  use. 

utilities. cmp 
utilities. cmp^out 
utilities. obj 


The  compool  >udd>Flowchart>Voydock>Library>utilities.cmp_out 
is  automatically  used  by  the  Jovial  command  for  every 
compilation.  It  contains  the  proper  declarations  for  the 
following  items. 


External  procedures* 

trmout  print  a character  string  on  the  terminal 
suppressing  leading  blanks 

tout  print  a portion  of  a character  string  on  the 

terminal 

trmin  read  a line  typed  at  the  terminal  into  a 

character  string 

frstnb  return  the  index  of  the  first  nonblank  character 
in  a string 

i 
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Currently  useless* 

The  following  two  declarations  will  eventually  allow  the 
user  to  divert  the  output  of  "monitor"  statements  to  a 
segment  other  than  the  "run. list"  segment.  Since  the  J'file 


1 
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I procedure  described  in  the  Jocit  manual  does  not  currently 

work  (any  program  which  invokes  it  blows  up),  these  Items 
are  not  of  current  interest.  They  are  included  for 
completeness. 

file  mon^output  h 1 r 132  v(null)  10$ 

proc  J-'f  ileCmon-'output'fi  le)  $ 


trmout.gmap  trmout.obj 


: The  procedure  trmout  allows  a JOVIAL  program  to  print  a 
( character  string  of  any  length  on  the  terminal.  Leading 
i blanks,  if  any,  are  suppressed.  Since  the  procedure  is 
i declared  in  utilities.cmp_out,  it  can  (and  must)  be  used  in 
: a JOVIAL  program  without  being  declared. 


Syntax* 

trmout(char'string,  str^lng)$ 


Arguments* 

char^string 


str' Ing 


trmin.gfort  trmin.obj 


The  procedure  trmin  allows  a JOVIAL  program  to  read  a line 
typed  at  the  terminal  into  a character  string.  This 
character  string  may  be  of  any  length.  If  the  line  typed  is 
shorter  than  the  string,  it  is  stored  right  adjusted  with 
leading  blanks.  Since  the  procedure  is  declared  in 
util ities.cmp_out,  it  can  (and  must)  be  used  in  a JOVIAL 


is  any  character  string  known  to  the  program 
in  which  the  call  to  trmout  is  located. 

is  the  length  of  the  string  in  characters. 

It  should  either  be  a constant  or  declared 
with  the  following  declaration* 

i 

item  s trying  i 35  u$  j 


I 


63 


program  without  being  declared. 


Syntax* 

trmin(char^string»  str'lng)$ 


Arguments* 

char^strlng  is  any  character  string  known  to  the  program 

in  which  the  call  to  trmin  is  located. 

str^lng  is  the  length  of  the  string  in  chaiacters. 

It  should  either  be  a constant  or  declared 
with  the  following  declaration* 

item  str'lng  1 35  u$ 


tout.gfort  tout.obj 


The  procedure  tout  allows  a JOVIAL  program  to  print  part  of 
a character  string  on  the  terminal.  The  character  string 
may  be  of  any  length.  Since  the  procedure  is  declared  in 
utilities. cmp_outt  it  can  (and  must)  be  used  in  a JOVIAL 
program  without  being  declared. 


Syntax* 

tout(char^string,  first,  str-'lng)$ 


Arguments* 

char'string  is  any  character  string  known  to  the  program 

in  which  the  call  to  tout  is  located. 

first  the  rightmost  str^lng-f irst+ I characters 

of  char-'strlng  are  printed.  First  should 
be  declared  as  follows* 

item  first  i 35  u$ 
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str^lng  is  the  length  of  the  string  in  characters. 

It  should  either  be  a constant  or  declared 
with  the  following  declaration* 

item  str^lng  i 35  u$ 


frstnb.gmap  frstnb.obj 


The  function  frstnb  returns  the  index  of  the  first  nonblank 
character  in  a specified  character  string.  This  string  may 
be  of  any  length.  Since  the  procedure  is  declared  in 
utilities. cmp_out,  it  can  (and  must)  be  used  in  a JOVIAL 
program  without  being  declared. 


Syntax* 

lndex=frstnb( char' string,  str'lng)$ 


Arguments* 

index  is  the  index  of  the  first  nonblank  character  in 

char'string.  The  count  is  from  the  left!  the  index 
of  the  left  most  character  is  one.  If  the  string 
contains  no  leading  blanks  then  index  is  set  to  zero. 
Index  should  be  declared  as  follows* 

item  index  i 35  u$ 

char'string  is  any  character  string  known  to  the  program 
in  which  the  call  to  frstnb  is  located. 

str'lng  is  the  length  of  the  string  in  characters. 

It  should  either  be  a constant  or  declared 
with  the  following  declaration* 

item  str'lng  i 35  u$ 
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